Date: Tue, 16 Jul 2013 20:16:48 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, "Robert N. M. Watson" <rwatson@freebsd.org>, Jilles Tjoelker <jilles@stack.nl>, freebsd-arch@freebsd.org Subject: Re: Extending MADV_PROTECT Message-ID: <20130716171648.GI5991@kib.kiev.ua> In-Reply-To: <201307161130.40737.jhb@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <201307121748.57778.jhb@freebsd.org> <20130713175835.GN91021@kib.kiev.ua> <201307161130.40737.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--1Y7d0dPL928TPQbc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 11:30:40AM -0400, John Baldwin wrote: > On Saturday, July 13, 2013 1:58:35 pm Konstantin Belousov wrote: > > On Fri, Jul 12, 2013 at 05:48:57PM -0400, John Baldwin wrote: > > > On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > > > > Ok, there isn't really a clear consensus here, but I need a system = call to let > > > > me toggle this flag on existing processes. > > > >=20 > > > > One reason I don't like the procctl() approach is I am uneasy about= forcing > > > > a certain behavior for how commands treat pgid (first-fail vs best-= effort). > > > > I guess it can always change in the future so that isn't completely= unsolvable. > > > >=20 > > > > I guess I am fine just making it use hardcoded sizes instead of ful= l-blown > > > > ioctl encoding. > > >=20 > > > Ok, I have updated patches for this for HEAD. I have not yet impleme= nted the > > > inheritance bits because I'm loathe to add the first bit to a p_flag2= =2E :-P > > > However, if that's the best course of action I suppose we can do that. > > >=20 > > > The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch > > >=20 > > > The patch for the protect binary is at www.freebsd.org/~jhb/patches/p= rotect.patch > > >=20 > >=20 > > It seems that p_cansee() is called twice, once in kern_procctl(), and > > then in protect_setchild(). >=20 > Yes, this is because protect_setchild() can descend to child processes, a= nd > you might not be able to "see" a child process if it exec'd a suid binary= , etc. >=20 > > Is AUE_WAIT6 the correct audit event id for procctl ? >=20 > Nope. (It probably needs a new one?) Yes, probably needs a new id. > =20 > > I thought proposing to use pget() for P_PID case in kern_procctl(), but > > indeed open coding of the process lookup is easier, since otherwise > > you would need to move proctree_lock acquisition to P_PGID. > >=20 > > Why do you need PPROT_CLEAR ? If you do need the flag, would it be bet= ter > > to assign a non-zero value to it ? >=20 > I need it for 'protect -c' which is similar to 'ktrace -C'. That is, to > allow protection to be removed from existing processes. I added a consta= nt > for it to make the code clear as the caller should pick one of PPROT_SET > or PPROT_CLEAR (kind of like MAP_PRIVATE vs MAP_SHARED for mmap(2)). Oth= erwise > you would have 'procctl(..., PROC_SPROTECT, 0)' which is not as obvious > to me as ', PPROT_CLEAR)'. Also, you can do 'PPROT_CLEAR | PPROT_DESCEND' > to clear it for all descendants. Having 'PPROT_SET | PPROT_DESCEND' to s= et > it for descendenats and just 'PPROT_DESCEND' to clear for descendants doe= sn't > seem as readable. Well, I think that assigning non-zero value is justified. >=20 > Do you have any thoughts on p_flag2 (vs some other approach, possibly I > should create a new field for oom-specific flags instead since we may > eventually store a priority there?) p_flag2 is inevitable, it seems. It would be added now, or, even if you could avoid this, in the nearest future. I do not like mixing a flag and a priority-like field. --1Y7d0dPL928TPQbc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR5X//AAoJEJDCuSvBvK1B8u4P/RftpKukYPJgbQdOXJVsTk1r LVY5VqJQZfGHGd3xt5Oqzz+KPAmQvC8aX5cnU+KF+ISz9d2JDYvbZmjI3F7oHoYN /vvMw6tuNdnLs8Tf+TV8FEf6VvQYG7yCapMZ+D91YVQIA4igJz1vk+pNtW+QppBb klS/cvjHnVX8dzOPHj9iRroTF/CJA+9PF13GIbA+cZGi0nfubyhI/jlscOVm8LGt geyKn7vqlp4xOQSg2iOCYeMEl+dTpelRkRDemuoBtaNZq0xN+vokpaDUH651vNuk kCgljz+ENuBfzbp+x7i2/j5L7+cKPkdpzNaVTTWTMmE7GQ5G33yfTwrpgXTpo+Br n0SKkWf/ii5XJiF25HICBhEPXFMYrUhGNQMNbePTrYGg7N3/Apc31h2QutJ0Namu c9TBqLUYVl+3/EPZTsxv6tzbFULCjoNgzWdDSlu6r4/MRKFGX/xWKqkTw5TY9j02 h0ItB5DK3J0sAjIHNCRWP9i3eDc84m6x4+Ar4IQglYo4PEGtjEhAWQkaG/eXgkJn kuVg4/N5u2FjnDKYypY9n9s2I9p+vAwxbpEhXdtlM2NU6bDhvky0QonMOThVJDC/ Y+oRqgiHlYzjA11M1s/299HfEGfCoHF12FV/QQTiYyLAnknNH5tQqKTHLP++qmxF zJ+T4rDtHOWTLEHxq+s/ =OoaF -----END PGP SIGNATURE----- --1Y7d0dPL928TPQbc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130716171648.GI5991>