Extending MADV_PROTECT

Konstantin Belousov kostikbel at gmail.com
Wed May 22 08:41:53 UTC 2013


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130522/7df1a757/attachment.sig>


More information about the freebsd-arch mailing list