From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36530C4CECD for ; Mon, 27 Apr 2020 18:59:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 20C23214AF for ; Mon, 27 Apr 2020 18:59:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726420AbgD0S7m (ORCPT ); Mon, 27 Apr 2020 14:59:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726260AbgD0S7m (ORCPT ); Mon, 27 Apr 2020 14:59:42 -0400 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1790DC0610D5; Mon, 27 Apr 2020 11:59:42 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 499vGK29VXzQlH3; Mon, 27 Apr 2020 20:59:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id q-xPfyQwqZzM; Mon, 27 Apr 2020 20:59:33 +0200 (CEST) Date: Mon, 27 Apr 2020 20:59:29 +0200 From: Hagen Paul Pfeifer To: "Eric W. Biederman" Cc: Jann Horn , Christian Brauner , kernel list , Florian Weimer , Al Viro , Christian Brauner , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Arnd Bergmann , Brian Gerst , Sami Tolvanen , David Howells , Aleksa Sarai , Andy Lutomirski , Oleg Nesterov , Arnaldo Carvalho de Melo , Sargun Dhillon , Linux API , linux-arch , Linus Torvalds , Greg Kroah-Hartman Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall Message-ID: <20200427185929.GA1768@laniakea> References: <20200426130100.306246-1-hagen@jauu.net> <20200426163430.22743-1-hagen@jauu.net> <20200427170826.mdklazcrn4xaeafm@wittgenstein> <87zhawdc6w.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhawdc6w.fsf@x220.int.ebiederm.org> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 X-Rspamd-Queue-Id: A09E7176C X-Rspamd-Score: 0.58 / 15.00 / 15.00 Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org * Eric W. Biederman | 2020-04-27 13:18:47 [-0500]: >I am conflicted about that but I have to agree. Instead of >duplicating everything it would be good enough to duplicate the once >that cause the process to be attached to use. Then there would be no >more pid races to worry about. >How does this differ using the tracing related infrastructure we have >for the kernel on a userspace process? I suspect augmenting the tracing >infrastructure with the ability to set breakpoints and watchpoints (aka >stopping userspace threads and processes might be a more fertile >direction to go). > >But I agree either we want to just address the races in PTRACE_ATTACH >and PTRACE_SIEZE or we want to take a good hard look at things. > >There is a good case for minimal changes because one of the cases that >comes up is how much work will it take to change existing programs. But >ultimately ptrace pretty much sucks so a very good set of test cases and >documentation for what we want to implement would be a very good idea. Hey Eric, Jann, Christian, Arnd, thank you for your valuable input! IMHO I think we have exactly two choices here: a) we go with my patchset that is 100% ptrace feature compatible - except the pidfd thing - now and in the future. If ptrace is extended pidfd_ptrace is automatically extended and vice versa. Both APIs are feature identical without any headaches. b) leave ptrace completely behind us and design ptrace that we have always dreamed of! eBPF filters, ftrace kernel architecture, k/uprobe goodness, a speedy API to copy & modify large chunks of data, io_uring/epoll support and of course: pidfd based (missed likely thousands of other dreams) I think a solution in between is not worth the effort! It will not be compatible in any way for the userspace and the benefit will be negligible. Ptrace is horrible API - everybody knows that but developers get comfy with it. You find examples everywhere, why should we make it harder for the user for no or little benefit (except that stable handle with pidfd and some cleanups)? Any thoughts on this? Hagen