From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksa Sarai Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall Date: Tue, 28 Apr 2020 10:45:46 +1000 Message-ID: <20200428004546.mlpwixgms2ekpfdm@yavin.dot.cyphar.com> References: <20200426130100.306246-1-hagen@jauu.net> <20200426163430.22743-1-hagen@jauu.net> <20200427170826.mdklazcrn4xaeafm@wittgenstein> <87zhawdc6w.fsf@x220.int.ebiederm.org> <20200427185929.GA1768@laniakea> <20200427201303.tbiipopeapxofn6h@wittgenstein> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3oqbxiocwy4jimao" Return-path: Content-Disposition: inline In-Reply-To: <20200427201303.tbiipopeapxofn6h@wittgenstein> Sender: linux-kernel-owner@vger.kernel.org To: Christian Brauner Cc: Arnd Bergmann , Hagen Paul Pfeifer , "Eric W. Biederman" , Jann Horn , kernel list , Florian Weimer , Al Viro , Christian Brauner , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Brian Gerst , Sami Tolvanen , David Howells , Andy Lutomirski , Oleg Nesterov , Arnaldo Carvalho de Melo , Sargun Dhillon , Linux API , linux-arch List-Id: linux-arch.vger.kernel.org --3oqbxiocwy4jimao Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-04-27, Christian Brauner wrote: > On Mon, Apr 27, 2020 at 10:08:03PM +0200, Arnd Bergmann wrote: > > The way I understood Jann was that instead of a new syscall that duplic= ates > > everything in ptrace(), there would only need to be a new ptrace request > > such as PTRACE_ATTACH_PIDFD that behaves like PTRACE_ATTACH > > but takes a pidfd as the second argument, perhaps setting the return va= lue > > to the pid on success. Same for PTRACE_SEIZE. >=20 > That was my initial suggestion, yes. Any enum that identifies a target > by a pid will get a new _PIDFD version and the pidfd is passed as pid_t > argument. That should work and is similar to what I did for waitid() > P_PIDFD. Realistically, there shouldn't be any system where pid_t is > smaller than an int that we care about. >=20 > > In effect this is not much different from your a), just a variation on = the > > calling conventions. The main upside is that it avoids adding another > > ugly interface, the flip side is that it makes the existing one slightl= y worse > > by adding complexity. >=20 > Basically, if a new syscall than please a proper re-design with real > benefits. >=20 > In the meantime we could make due with the _PIDFD variant. And then if > someone wants to do the nitty gritty work of adding a ptrace variant > purely based on pidfds and with a better api and features that e.g. Jann > pointed out then by all means, please do so. I'm sure we would all > welcome this as well. I agree. It would be a shame to add a new ptrace syscall and not take the opportunity to fix the multitude of problems with the existing API. But that's a Pandora's box which we shouldn't open unless we want to wait a long time to get an API everyone is okay with -- a pretty high price to just get pidfds support in ptrace. --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --3oqbxiocwy4jimao Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXqd8tgAKCRCdlLljIbnQ EgHUAP0eXsMeBvX6165xj8TEMgh4rB2Aum2qA+WKvKBlmmoq6AD/UQdz5i+S0aA6 FmHhKfcX0nKnO3Qpss//v+w7UiJH/AQ= =FQhY -----END PGP SIGNATURE----- --3oqbxiocwy4jimao-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-102.mailbox.org ([80.241.56.152]:11350 "EHLO mout-p-102.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726337AbgD1AqQ (ORCPT ); Mon, 27 Apr 2020 20:46:16 -0400 Date: Tue, 28 Apr 2020 10:45:46 +1000 From: Aleksa Sarai Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall Message-ID: <20200428004546.mlpwixgms2ekpfdm@yavin.dot.cyphar.com> References: <20200426130100.306246-1-hagen@jauu.net> <20200426163430.22743-1-hagen@jauu.net> <20200427170826.mdklazcrn4xaeafm@wittgenstein> <87zhawdc6w.fsf@x220.int.ebiederm.org> <20200427185929.GA1768@laniakea> <20200427201303.tbiipopeapxofn6h@wittgenstein> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3oqbxiocwy4jimao" Content-Disposition: inline In-Reply-To: <20200427201303.tbiipopeapxofn6h@wittgenstein> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Christian Brauner Cc: Arnd Bergmann , Hagen Paul Pfeifer , "Eric W. Biederman" , Jann Horn , kernel list , Florian Weimer , Al Viro , Christian Brauner , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Brian Gerst , Sami Tolvanen , David Howells , Andy Lutomirski , Oleg Nesterov , Arnaldo Carvalho de Melo , Sargun Dhillon , Linux API , linux-arch , Linus Torvalds , Greg Kroah-Hartman Message-ID: <20200428004546.suhK4WMILras6gI3orel076N6YlxhyiMR_DPo4Ckxl4@z> --3oqbxiocwy4jimao Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-04-27, Christian Brauner wrote: > On Mon, Apr 27, 2020 at 10:08:03PM +0200, Arnd Bergmann wrote: > > The way I understood Jann was that instead of a new syscall that duplic= ates > > everything in ptrace(), there would only need to be a new ptrace request > > such as PTRACE_ATTACH_PIDFD that behaves like PTRACE_ATTACH > > but takes a pidfd as the second argument, perhaps setting the return va= lue > > to the pid on success. Same for PTRACE_SEIZE. >=20 > That was my initial suggestion, yes. Any enum that identifies a target > by a pid will get a new _PIDFD version and the pidfd is passed as pid_t > argument. That should work and is similar to what I did for waitid() > P_PIDFD. Realistically, there shouldn't be any system where pid_t is > smaller than an int that we care about. >=20 > > In effect this is not much different from your a), just a variation on = the > > calling conventions. The main upside is that it avoids adding another > > ugly interface, the flip side is that it makes the existing one slightl= y worse > > by adding complexity. >=20 > Basically, if a new syscall than please a proper re-design with real > benefits. >=20 > In the meantime we could make due with the _PIDFD variant. And then if > someone wants to do the nitty gritty work of adding a ptrace variant > purely based on pidfds and with a better api and features that e.g. Jann > pointed out then by all means, please do so. I'm sure we would all > welcome this as well. I agree. It would be a shame to add a new ptrace syscall and not take the opportunity to fix the multitude of problems with the existing API. But that's a Pandora's box which we shouldn't open unless we want to wait a long time to get an API everyone is okay with -- a pretty high price to just get pidfds support in ptrace. --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --3oqbxiocwy4jimao Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXqd8tgAKCRCdlLljIbnQ EgHUAP0eXsMeBvX6165xj8TEMgh4rB2Aum2qA+WKvKBlmmoq6AD/UQdz5i+S0aA6 FmHhKfcX0nKnO3Qpss//v+w7UiJH/AQ= =FQhY -----END PGP SIGNATURE----- --3oqbxiocwy4jimao--