Extending MADV_PROTECT

Robert N. M. Watson rwatson at freebsd.org
Tue May 21 19:24:51 UTC 2013


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).

Robert


More information about the freebsd-arch mailing list