From owner-freebsd-arch@FreeBSD.ORG Fri Jun 28 18:46:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0CAA2A82; Fri, 28 Jun 2013 18:46:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id DCA971ECF; Fri, 28 Jun 2013 18:46:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A67DB91A; Fri, 28 Jun 2013 14:46:19 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Fri, 28 Jun 2013 14:46:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> In-Reply-To: <20130522084145.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201306281446.01797.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Jun 2013 14:46:19 -0400 (EDT) Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 18:46:21 -0000 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