From owner-freebsd-arch@FreeBSD.ORG Sat Jun 29 15:08:10 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 32B1F7F0; Sat, 29 Jun 2013 15:08:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8193C1981; Sat, 29 Jun 2013 15:08:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5TF84wF045022; Sat, 29 Jun 2013 18:08:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5TF84wF045022 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5TF84WL045021; Sat, 29 Jun 2013 18:08:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 29 Jun 2013 18:08:04 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130629150804.GC91021@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> <201306281446.01797.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VNNQie1NYARlNv6L" Content-Disposition: inline In-Reply-To: <201306281446.01797.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Sat, 29 Jun 2013 15:08:10 -0000 --VNNQie1NYARlNv6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > >=20 > > > On 21 May 2013, at 12:22, John Baldwin wrote: > > >=20 > > > >> If it is ioctl-like, it is possible to redirect ioctl() on a proce= ss > > > >> 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 pr= ocess > > > >> by process descriptor. Capsicum may then need more CAP_*. > > > >=20 > > > > I talked to Robert about this in person at BSDCan and he indeed doe= s not=20 > > > > prefer general purpose multiplexers for system calls. In particula= r it does=20 > > > > make auditing and access control for such things a lot harder to do= =2E My=20 > > > > impression from my discussion with him is that he would actually pr= efer much=20 > > > > more narrowly focused system calls (so pprotect() in this case rath= er than a=20 > > > > generic procctl()). > > >=20 > > > 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). > >=20 > > 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. >=20 > Ok, there isn't really a clear consensus here, but I need a system call t= o let > me toggle this flag on existing processes. >=20 > One reason I don't like the procctl() approach is I am uneasy about forci= ng > 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 unsol= vable. >=20 > 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 structu= res sizes) most. But I repeat myself. Also, I think that best efforts is fair, while first fail causes unpredicta= ble behaviour. My 0.02UAH, sorry for causing this discussion at all. --VNNQie1NYARlNv6L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzvhUAAoJEJDCuSvBvK1BPVIQAJ7moQaM3Kf//hJswXKNeyxM 1bXFIYQnhn6dEPN9jtDdUe0jdjd6Q42wXpwAHR5y0eQKzoVFLoLrmkHzM/wR4dUz PWvlRnBiJdrIX8W5to2jtiHSxfpMKJamJ2u8VT5FPsMCuDXoyRz6Wz/2Egc4F3nx ljCaroMJSJTF5QALGcTKFwsJ4/j/o02KXWVB8R4kuTvy5BDNC680RFdHw4DScTGH XYWRLdGI+p6ZPd3fRgXP+gf9bHOoXO236opwYBSwI28vXpSgJbrh1nmdKlO+9DH5 zUtGrW9VMpLQ1ub4sRpKHmEiIug17Q2q8TyxPAbJGBeE3tQKTvl37cpQvf5o3R/2 XqW0z/wyxzTjv4Dw0EDFr8j58KMCEVnJaG4D+Oo4Adg0V3kyinUoi4OOLuPE8cQa ImLfqLnANy1Z8iDU7e2yW4fT/hUpcFSD3GHPv2kjguJnyp2JkUTCyRN9JgjBEh5g JEsClyr6toW4rLugVQDae/x8UnzFmKVUJ0mB/ubYhMtVFO+1zcVLfPBFQTzP5mMW 1lACxk+mKqkBI98DakrIVx1zHytY1OPkXdlNWdvcchWpQlmOaganmkixMBVUXQVk B57aXE53MgPbptFlHpDuALlNYtZCXAIlvu1si1mxQcUI7jrQV3jaVrl9aJ3lWNJI duPVfcN75WXKv89hdD8i =VTcG -----END PGP SIGNATURE----- --VNNQie1NYARlNv6L--