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 DDD7CC83000 for ; Tue, 28 Apr 2020 07:45:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3DEE206D6 for ; Tue, 28 Apr 2020 07:45:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726274AbgD1HpT (ORCPT ); Tue, 28 Apr 2020 03:45:19 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:33576 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726256AbgD1HpT (ORCPT ); Tue, 28 Apr 2020 03:45:19 -0400 Received: from ip5f5af183.dynamic.kabel-deutschland.de ([95.90.241.131] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jTKvQ-00077O-8t; Tue, 28 Apr 2020 07:45:04 +0000 Date: Tue, 28 Apr 2020 09:45:02 +0200 From: Christian Brauner To: Hagen Paul Pfeifer Cc: Linus Torvalds , Andy Lutomirski , Aleksa Sarai , Arnd Bergmann , "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 , Greg Kroah-Hartman Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall Message-ID: <20200428074502.ruqlxqqgnoyqvhwv@wittgenstein> References: <20200428063935.GA5660@laniakea> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200428063935.GA5660@laniakea> Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Apr 28, 2020 at 08:39:35AM +0200, Hagen Paul Pfeifer wrote: > * Linus Torvalds | 2020-04-27 21:28:14 [-0700]: > > >> I hate to say this, but I’m not convinced that asking the gdb folks is > >> the right approach. GDB has an ancient architecture and is > >> *incredibly* buggy. I’m sure ptrace is somewhere on the pain point > >> list, but I suspect it’s utterly dwarfed by everything else. > > > >You may be right. However, if gdbn isn't going to use it, then I > >seriously don't think it's worth changing much. > > > >It might be worth looking at people who don't use ptrace() for > >debugging, but for "incidental" reasons. IOW sandboxing, tracing, > >things like that. > > > >Maybe those people want things that are simpler and don't actually > >need the kinds of hard serialization that ptrace() wants. > > > >I'd rather add a few really simple things that might not be a full > >complement of operations for a debugger, but exactly because they > >aren't a full debugger, maybe they are things that we can tell are > >obviously secure and simple? > > Okay, to sum up the the whole discussion: we go forward with Jann's proposal > by simple adding PTRACE_ATTACH_PIDFD and friends. This is the minimal invasive > solution and the risk of an potenial security problem is almost not present[TM]. > > Changing the whole ptrace API is a different beast. I rather believe that I > see Linus Linux successor rather than a ptrace successor. > > I am fine with PTRACE_ATTACH_PIDFD! If this is enough for you use-case then we should make due with my initial suggestion, yes. I'd be fine with adding this variant. I initially thought that we'd likely would need to support a few more but I don't think we want to actually; there's a bunch of crazy stuff in there. Christian