Date: Sat, 29 Jun 2013 18:08:04 +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> Subject: Re: Extending MADV_PROTECT Message-ID: <20130629150804.GC91021@kib.kiev.ua> In-Reply-To: <201306281446.01797.jhb@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> <201306281446.01797.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--VNNQie1NYARlNv6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 02:46:01PM -0400, John Baldwin wrote: > On Wednesday, May 22, 2013 4:41:45 am Konstantin Belousov wrote: > > On Tue, May 21, 2013 at 03:24:50PM -0400, Robert N. M. Watson wrote: > > >=20 > > > On 21 May 2013, at 12:22, John Baldwin wrote: > > >=20 > > > >> If it is ioctl-like, it is possible to redirect ioctl() on a proce= ss > > > >> descriptor to procctl and use cap_ioctls_limit() infrastructure. I= 'm not > > > >> sure Capsicum people actually like that, though. > > > >>=20 > > > >> In either case, it is possible to have a P_PROCDESC to affect a pr= ocess > > > >> by process descriptor. Capsicum may then need more CAP_*. > > > >=20 > > > > I talked to Robert about this in person at BSDCan and he indeed doe= s not=20 > > > > prefer general purpose multiplexers for system calls. In particula= r it does=20 > > > > make auditing and access control for such things a lot harder to do= =2E My=20 > > > > impression from my discussion with him is that he would actually pr= efer much=20 > > > > more narrowly focused system calls (so pprotect() in this case rath= er than a=20 > > > > generic procctl()). > > >=20 > > > Yes -- based on experience with Capsicum, audit, but also things > > like ktrace, LD_PRELOAD, etc, I have a strong preference for not using > > ioctl for first-class (global) functions. We shouldn't go crazy on > > new system calls, but key new abstraction functions in the kernel do > > reasonably deserve new APIs. Matching pprotect() and pdprotect() APIs > > sound plausible to me (without skimming back through the thread too > > much). > >=20 > > I agree with statement that an ioctl()-like interface for the syscall > > is too wide, and I stated this already. On the other hand, I believe > > that e.g. ptrace(2) is fine as is, and splitting it into 20-30 syscalls > > each performing single ptrace operation would be a mistake. The same, > > IMO, holds for the procctl() syscall, which is better not split into > > pprotect(), then some improved version of pprotect() etc. I would prefer > > to not have proliferation of the FreeBSD-specific process-controlling > > syscalls, which could be cumulated in the single entry and single man > > page. >=20 > Ok, there isn't really a clear consensus here, but I need a system call t= o let > me toggle this flag on existing processes. >=20 > One reason I don't like the procctl() approach is I am uneasy about forci= ng > 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 unsol= vable. >=20 > I guess I am fine just making it use hardcoded sizes instead of full-blown > ioctl encoding. I definitely like the ptrace-style syscall (i.e. hardcoded argument structu= res sizes) most. But I repeat myself. Also, I think that best efforts is fair, while first fail causes unpredicta= ble behaviour. My 0.02UAH, sorry for causing this discussion at all. --VNNQie1NYARlNv6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzvhUAAoJEJDCuSvBvK1BPVIQAJ7moQaM3Kf//hJswXKNeyxM 1bXFIYQnhn6dEPN9jtDdUe0jdjd6Q42wXpwAHR5y0eQKzoVFLoLrmkHzM/wR4dUz PWvlRnBiJdrIX8W5to2jtiHSxfpMKJamJ2u8VT5FPsMCuDXoyRz6Wz/2Egc4F3nx ljCaroMJSJTF5QALGcTKFwsJ4/j/o02KXWVB8R4kuTvy5BDNC680RFdHw4DScTGH XYWRLdGI+p6ZPd3fRgXP+gf9bHOoXO236opwYBSwI28vXpSgJbrh1nmdKlO+9DH5 zUtGrW9VMpLQ1ub4sRpKHmEiIug17Q2q8TyxPAbJGBeE3tQKTvl37cpQvf5o3R/2 XqW0z/wyxzTjv4Dw0EDFr8j58KMCEVnJaG4D+Oo4Adg0V3kyinUoi4OOLuPE8cQa ImLfqLnANy1Z8iDU7e2yW4fT/hUpcFSD3GHPv2kjguJnyp2JkUTCyRN9JgjBEh5g JEsClyr6toW4rLugVQDae/x8UnzFmKVUJ0mB/ubYhMtVFO+1zcVLfPBFQTzP5mMW 1lACxk+mKqkBI98DakrIVx1zHytY1OPkXdlNWdvcchWpQlmOaganmkixMBVUXQVk B57aXE53MgPbptFlHpDuALlNYtZCXAIlvu1si1mxQcUI7jrQV3jaVrl9aJ3lWNJI duPVfcN75WXKv89hdD8i =VTcG -----END PGP SIGNATURE----- --VNNQie1NYARlNv6L--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130629150804.GC91021>