Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3822995ybz; Tue, 28 Apr 2020 00:47:18 -0700 (PDT) X-Google-Smtp-Source: APiQypJH/JcEQTVO6Em8uN8LBYO/DSyxfx1nBHHq2eF75yOfM2Arj5rYGg3yK64OcErm1YTpBgiy X-Received: by 2002:a17:907:2142:: with SMTP id rk2mr24192780ejb.356.1588060038402; Tue, 28 Apr 2020 00:47:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588060038; cv=none; d=google.com; s=arc-20160816; b=WFBVdUcRm2HTecfc3EyFuMpieH8Xy8iP7tY7+PtslFM0HvnnRn6CkGMfZFIDj7nrTS nbo/6zY7LdHJ3BKuhJM42QbnhAzi84Gl/Zy9C01dLmj1IFuc77Zf2ygJitFOeKR11kQL nudEOALlLAsnnbLQuWw2yhPjZo4UG0CDXsd99yWCgZDOwRhbcY+MJUO+1b3+K0Sdmfpo +1TGp3WxCwVssNiWtU770IWMKCwTgO8mpFGnibwaoVNYfw/iBIBcZ6laTmEJoJeSfsEY eAnG+r3LPx4B17UdDhuR+v+zI7oT+JCZIi4GUt+nn/UbNbzW1+KjVlKt27OOxY0QbkMX eseg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=48FlrtEXcffbKjiCvEVWbj8DKFsR99yiN4mQrVcLaJo=; b=s6rBvBwnnjtuk0qlYSIuwpZhLihQjjwODG7j2p8e9q8BTEZzuufuGrfRptspZPKLfi lySNEwDlvejItt2SSsr4ZemZhGfK43C6qlPDdtp9oysuWT/ng6fIS8ZI5DL+z73Sa0nr 3NoTfKJVv4E3ryOo8Y/flyTCmcv+pNdJMbMB+O5i1kQZRA8FWDNNxix1gnAMwVJTwtoW rng29uxxFpYcsvyG6deDuLKM4gLF8pd0s9WBc9IUewCk3hHdj+kBqk2KK7pCj2YBfAL5 6LvW7JNEXhEOK9Tyzt4EG8M6GGPNDEQuH3NgXeX+Z8mDwT2M/t8wDyVKJp1cjgEXu4zY Eehw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j3si1299815edr.148.2020.04.28.00.46.55; Tue, 28 Apr 2020 00:47:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726561AbgD1HpT (ORCPT + 99 others); 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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