Extending MADV_PROTECT

[Konstantin Belousov]

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

I definitely like the ptrace-style syscall (i.e. hardcoded argument structures
sizes) most.  But I repeat myself.

Also, I think that best efforts is fair, while first fail causes unpredictable
behaviour.

My 0.02UAH, sorry for causing this discussion at all.
-------------- 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/20130629/f6161633/attachment.sig>