Date: Fri, 28 Jun 2013 14:46:01 -0400 From: John Baldwin <jhb@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, "Robert N. M. Watson" <rwatson@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Extending MADV_PROTECT Message-ID: <201306281446.01797.jhb@freebsd.org> In-Reply-To: <20130522084145.GJ3047@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > > On 21 May 2013, at 12:22, John Baldwin wrote: > > > > >> If it is ioctl-like, it is possible to redirect ioctl() on a process > > >> descriptor to procctl and use cap_ioctls_limit() infrastructure. I'm not > > >> sure Capsicum people actually like that, though. > > >> > > >> In either case, it is possible to have a P_PROCDESC to affect a process > > >> by process descriptor. Capsicum may then need more CAP_*. > > > > > > I talked to Robert about this in person at BSDCan and he indeed does not > > > prefer general purpose multiplexers for system calls. In particular it does > > > make auditing and access control for such things a lot harder to do. My > > > impression from my discussion with him is that he would actually prefer much > > > more narrowly focused system calls (so pprotect() in this case rather than a > > > generic procctl()). > > > > 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). > > 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. Ok, there isn't really a clear consensus here, but I need a system call to let me toggle this flag on existing processes. 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. I guess I am fine just making it use hardcoded sizes instead of full-blown ioctl encoding. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306281446.01797.jhb>