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=-3.8 required=3.0 tests=BAYES_00, 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 6DBC0C433E2 for ; Mon, 7 Sep 2020 08:33:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9435208C7 for ; Mon, 7 Sep 2020 08:33:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9435208C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA62A6B005D; Mon, 7 Sep 2020 04:33:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A55866B0062; Mon, 7 Sep 2020 04:33:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F7026B0068; Mon, 7 Sep 2020 04:33:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 779E56B005D for ; Mon, 7 Sep 2020 04:33:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2B7B51F08 for ; Mon, 7 Sep 2020 08:33:18 +0000 (UTC) X-FDA: 77235600876.01.roll86_5b10726270ca Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id F1A901004646C for ; Mon, 7 Sep 2020 08:33:17 +0000 (UTC) X-HE-Tag: roll86_5b10726270ca X-Filterd-Recvd-Size: 3545 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Sep 2020 08:33:17 +0000 (UTC) Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kFCaP-0003zW-JD; Mon, 07 Sep 2020 08:33:13 +0000 Date: Mon, 7 Sep 2020 10:33:12 +0200 From: Christian Brauner To: Paolo Bonzini Cc: Florian Weimer , Adalbert =?utf-8?B?TGF6xINy?= , linux-mm@kvack.org, linux-api@vger.kernel.org, Andrew Morton , Alexander Graf , Stefan Hajnoczi , Jerome Glisse , Mihai =?utf-8?B?RG9uyJt1?= , Mircea Cirjaliu , Andy Lutomirski , Arnd Bergmann , Sargun Dhillon , Aleksa Sarai , Oleg Nesterov , Jann Horn , Kees Cook , Matthew Wilcox Subject: Re: [RESEND RFC PATCH 0/5] Remote mapping Message-ID: <20200907083312.33wvjkqazbrsf3hg@wittgenstein> References: <20200904113116.20648-1-alazar@bitdefender.com> <87pn71gxi8.fsf@mid.deneb.enyo.de> <5447a405-4e4f-8034-eb86-ec2f6ddf45f0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5447a405-4e4f-8034-eb86-ec2f6ddf45f0@redhat.com> X-Rspamd-Queue-Id: F1A901004646C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hey Paolo, On Fri, Sep 04, 2020 at 10:18:17PM +0200, Paolo Bonzini wrote: > On 04/09/20 21:19, Florian Weimer wrote: > > I'm not sure what the advantage is of returning separate file > > descriptors, and nit operating directly on the pidfd. > > For privilege separation. So far, the common case of pidfd operations > has been that whoever possesses a pidfd has "power" over the target I may misunderstand you but that's actually not quite true. Currently, pidfds are just handles on processes and currently only convey identity. They don't guarantee any sort of privilege over the target process. We have had discussion to treat them more as a capability in the future but that needs to be carefully thought out. > process. Here however we also want to cover the case where one > privileged process wants to set up and manage a memory range for > multiple children. The privilege process can do so by passing the > access file descriptor via SCM_RIGHTS. > > We also want different children to have visibility over different > ranges, which is why there are multiple control fds rather than using > the pidfd itself as control fd. You could have the map/unmap/lock ioctl > on the pidfd itself and the access fd as an argument of the ioctl, but > it seems cleaner to represent the pidfd-mem control capability as its > own file descriptor. We have very much on purpose avoided adding ioctls() on top of pidfds and I'm not fond of the idea of starting to add them. Supporting ioctl()s on an fd usually opens up a can of worms and makes sneaking in questionable features more likely (I'm not saying your patchset does that!). If this interface holds up, I would ask you to please either keep this as a separate fd type or please propose system calls only. Christian