<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src-test2/lib/libprocstat/libprocstat.c, branch release/11.0.0</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.0.0</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.0.0'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/'/>
<updated>2015-10-06T18:07:00Z</updated>
<entry>
<title>Fix core corruption caused by race in note_procstat_vmmap</title>
<updated>2015-10-06T18:07:00Z</updated>
<author>
<name>Conrad Meyer</name>
<email>cem@FreeBSD.org</email>
</author>
<published>2015-10-06T18:07:00Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=e6b95927f39018d10fcfc39f8236525c72b84d06'/>
<id>urn:sha1:e6b95927f39018d10fcfc39f8236525c72b84d06</id>
<content type='text'>
This fix is spiritually similar to r287442 and was discovered thanks to
the KASSERT added in that revision.

NT_PROCSTAT_VMMAP output length, when packing kinfo structs, is tied to
the length of filenames corresponding to vnodes in the process' vm map
via vn_fullpath.  As vnodes may move during coredump, this is racy.

We do not remove the race, only prevent it from causing coredump
corruption.

- Add a sysctl, kern.coredump_pack_vmmapinfo, to allow users to disable
  kinfo packing for PROCSTAT_VMMAP notes.  This avoids VMMAP corruption
  and truncation, even if names change, at the cost of up to PATH_MAX
  bytes per mapped object.  The new sysctl is documented in core.5.

- Fix note_procstat_vmmap to self-limit in the second pass.  This
  addresses corruption, at the cost of sometimes producing a truncated
  result.

- Fix PROCSTAT_VMMAP consumers libutil (and libprocstat, via copy-paste)
  to grok the new zero padding.

Reported by:	pho (https://people.freebsd.org/~pho/stress/log/datamove4-2.txt)
Relnotes:	yes
Sponsored by:	EMC / Isilon Storage Division
Differential Revision:	https://reviews.freebsd.org/D3824
</content>
</entry>
<entry>
<title>Detect badly behaved coredump note helpers</title>
<updated>2015-09-03T20:32:10Z</updated>
<author>
<name>Conrad Meyer</name>
<email>cem@FreeBSD.org</email>
</author>
<published>2015-09-03T20:32:10Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=14bdbaf2e40a827e84f6c2fe27b1f8229767f03c'/>
<id>urn:sha1:14bdbaf2e40a827e84f6c2fe27b1f8229767f03c</id>
<content type='text'>
Coredump notes depend on being able to invoke dump routines twice; once
in a dry-run mode to get the size of the note, and another to actually
emit the note to the corefile.

When a note helper emits a different length section the second time
around than the length it requested the first time, the kernel produces
a corrupt coredump.

NT_PROCSTAT_FILES output length, when packing kinfo structs, is tied to
the length of filenames corresponding to vnodes in the process' fd table
via vn_fullpath.  As vnodes may move around during dump, this is racy.

So:

 - Detect badly behaved notes in putnote() and pad underfilled notes.

 - Add a fail point, debug.fail_point.fill_kinfo_vnode__random_path to
   exercise the NT_PROCSTAT_FILES corruption.  It simply picks random
   lengths to expand or truncate paths to in fo_fill_kinfo_vnode().

 - Add a sysctl, kern.coredump_pack_fileinfo, to allow users to
   disable kinfo packing for PROCSTAT_FILES notes.  This should avoid
   both FILES note corruption and truncation, even if filenames change,
   at the cost of about 1 kiB in padding bloat per open fd.  Document
   the new sysctl in core.5.

 - Fix note_procstat_files to self-limit in the 2nd pass.  Since
   sometimes this will result in a short write, pad up to our advertised
   size.  This addresses note corruption, at the risk of sometimes
   truncating the last several fd info entries.

 - Fix NT_PROCSTAT_FILES consumers libutil and libprocstat to grok the
   zero padding.

With suggestions from:	bjk, jhb, kib, wblock
Approved by:	markj (mentor)
Relnotes:	yes
Sponsored by:	EMC / Isilon Storage Division
Differential Revision:	https://reviews.freebsd.org/D3548
</content>
</entry>
<entry>
<title>Remove unused variable spotted by clang.</title>
<updated>2015-06-01T06:05:53Z</updated>
<author>
<name>Marcelo Araujo</name>
<email>araujo@FreeBSD.org</email>
</author>
<published>2015-06-01T06:05:53Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=a770b4d8ae6633c99e5ab0638ea2d04f028e8d26'/>
<id>urn:sha1:a770b4d8ae6633c99e5ab0638ea2d04f028e8d26</id>
<content type='text'>
Differential Revision:	D2685
Reviewed by:		rodrigc, stas
</content>
</entry>
<entry>
<title>Update most userspace consumers of capability.h to use capsicum.h instead.</title>
<updated>2014-03-16T11:04:44Z</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2014-03-16T11:04:44Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=b881b8be1d26495f5b41002c768c7c705e68fcef'/>
<id>urn:sha1:b881b8be1d26495f5b41002c768c7c705e68fcef</id>
<content type='text'>
auditdistd is not updated as I will make the change upstream and then do a
vendor import sometime in the next week or two.

MFC after:	3 weeks
</content>
</entry>
<entry>
<title>When querying a process's umask via sysctl in libprocstat(), don't</title>
<updated>2014-03-02T13:26:08Z</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2014-03-02T13:26:08Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=09b46be1cdaeb98b2f3fba1c6d4662fa2bea68d1'/>
<id>urn:sha1:09b46be1cdaeb98b2f3fba1c6d4662fa2bea68d1</id>
<content type='text'>
print a warning if EPERM is returned as this is an expected failure
mode rather than error -- similar to current handling of ESRCH.
This makes the output of 'procstat -as' vastly more palatable.

MFC after:	3 days
Sponsored by:	DARPA, AFRL
</content>
</entry>
<entry>
<title>Handle the cases where NULL is passed as cap_rightsp to the</title>
<updated>2013-10-09T20:58:50Z</updated>
<author>
<name>Pawel Jakub Dawidek</name>
<email>pjd@FreeBSD.org</email>
</author>
<published>2013-10-09T20:58:50Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=772f66457abf8907811c63af06afe7c7faac7d77'/>
<id>urn:sha1:772f66457abf8907811c63af06afe7c7faac7d77</id>
<content type='text'>
filestat_new_entry() function.

Reported by:	Alex Kozlov &lt;spam@rm-rf.kiev.ua&gt;
Approved by:	re (gjb)
</content>
</entry>
<entry>
<title>Change the cap_rights_t type from uint64_t to a structure that we can extend</title>
<updated>2013-09-05T00:09:56Z</updated>
<author>
<name>Pawel Jakub Dawidek</name>
<email>pjd@FreeBSD.org</email>
</author>
<published>2013-09-05T00:09:56Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=7008be5bd7341259037f383434a72960413cfeb8'/>
<id>urn:sha1:7008be5bd7341259037f383434a72960413cfeb8</id>
<content type='text'>
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

	struct cap_rights {
		uint64_t	cr_rights[CAP_RIGHTS_VERSION + 2];
	};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

	#define	CAP_PDKILL	CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

	#define	CAP_LOOKUP	CAPRIGHT(0, 0x0000000000000400ULL)
	#define	CAP_FCHMOD	CAPRIGHT(0, 0x0000000000002000ULL)

	#define	CAP_FCHMODAT	(CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

	cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
	void cap_rights_set(cap_rights_t *rights, ...);
	void cap_rights_clear(cap_rights_t *rights, ...);
	bool cap_rights_is_set(const cap_rights_t *rights, ...);

	bool cap_rights_is_valid(const cap_rights_t *rights);
	void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
	void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
	bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

	cap_rights_t rights;

	cap_rights_init(&amp;rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

	#define	cap_rights_set(rights, ...)				\
		__cap_rights_set((rights), __VA_ARGS__, 0ULL)
	void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

	cap_rights_init(&amp;rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by:	The FreeBSD Foundation
</content>
</entry>
<entry>
<title>- Trim an unused and bogus Makefile for mount_smbfs.</title>
<updated>2013-06-28T21:00:08Z</updated>
<author>
<name>Davide Italiano</name>
<email>davide@FreeBSD.org</email>
</author>
<published>2013-06-28T21:00:08Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=237abf0c56afd2f4846230b70b42b4c3d02d2d19'/>
<id>urn:sha1:237abf0c56afd2f4846230b70b42b4c3d02d2d19</id>
<content type='text'>
- Reconnect with some minor modifications, in particular now selsocket()
internals are adapted to use sbintime units after recent'ish calloutng
switch.
</content>
</entry>
<entry>
<title>Borrow the algorithm from kvm_getprocs() to fix procstat_getprocs() to</title>
<updated>2013-06-11T20:00:49Z</updated>
<author>
<name>John Baldwin</name>
<email>jhb@FreeBSD.org</email>
</author>
<published>2013-06-11T20:00:49Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=608203fd94e4558b9dd9073545871adeabd63650'/>
<id>urn:sha1:608203fd94e4558b9dd9073545871adeabd63650</id>
<content type='text'>
handle the case where the process tables grows in between the calls to
fetch the size and fetch the table.

MFC after:	1 week
</content>
</entry>
<entry>
<title>Make errbuf optional, so if a caller is not interested in an error</title>
<updated>2013-05-08T19:11:47Z</updated>
<author>
<name>Mikolaj Golub</name>
<email>trociny@FreeBSD.org</email>
</author>
<published>2013-05-08T19:11:47Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test2/commit/?id=467112b4d10e4aa4a63fd9ec81c2e155e0f68a7f'/>
<id>urn:sha1:467112b4d10e4aa4a63fd9ec81c2e155e0f68a7f</id>
<content type='text'>
message she can pass NULL (procstat(1) already does this).

MFC after:	2 weeks
</content>
</entry>
</feed>
