From owner-freebsd-arch@FreeBSD.ORG  Tue May 21 19:24:51 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 E0735899;
 Tue, 21 May 2013 19:24:51 +0000 (UTC)
 (envelope-from rwatson@freebsd.org)
Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69])
 by mx1.freebsd.org (Postfix) with ESMTP id BF74F875;
 Tue, 21 May 2013 19:24:51 +0000 (UTC)
Received: from [192.168.5.22] (ip-64-134-102-77.public.wayport.net
 [64.134.102.77])
 by cyrus.watson.org (Postfix) with ESMTPSA id E93C046B58;
 Tue, 21 May 2013 15:24:50 -0400 (EDT)
Subject: Re: Extending MADV_PROTECT
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: "Robert N. M. Watson" <rwatson@freebsd.org>
In-Reply-To: <201305211222.11236.jhb@freebsd.org>
Date: Tue, 21 May 2013 15:24:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBB4BD28-B803-4E26-851F-1F47506DD7A9@freebsd.org>
References: <201305071433.27993.jhb@freebsd.org> <5192AE7C.10105@FreeBSD.org>
 <20130520222825.GB43407@stack.nl> <201305211222.11236.jhb@freebsd.org>
To: John Baldwin <jhb@FreeBSD.org>
X-Mailer: Apple Mail (2.1283)
Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org,
 Jilles Tjoelker <jilles@stack.nl>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 19:24:51 -0000


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.
>>=20
>> In either case, it is possible to have a P_PROCDESC to affect a =
process
>> by process descriptor. Capsicum may then need more CAP_*.
>=20
> I talked to Robert about this in person at BSDCan and he indeed does =
not=20
> prefer general purpose multiplexers for system calls.  In particular =
it does=20
> make auditing and access control for such things a lot harder to do.  =
My=20
> impression from my discussion with him is that he would actually =
prefer much=20
> more narrowly focused system calls (so pprotect() in this case rather =
than a=20
> 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=