Extending MADV_PROTECT

[John Baldwin]

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