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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0DD6C77B78 for ; Wed, 19 Apr 2023 07:22:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232178AbjDSHW6 (ORCPT ); Wed, 19 Apr 2023 03:22:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231651AbjDSHWx (ORCPT ); Wed, 19 Apr 2023 03:22:53 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB6015247 for ; Wed, 19 Apr 2023 00:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681888923; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FCCYf58WbiV7ZwiVXeHUCjynN8kwG+K1Gw0EryKxlNA=; b=WfZehMATuXWzT50T29C0tmnzTsKu7KR9G3mnYIFMnGdtyH+uOzG/C3pXO6D2930usow23Q qSF23Crhzyq99ffbiElroWCgYYf2Xi1DPIcnQ137831DPgCVjSvHenkdYcAf1AjLOGlGSo kH4aGAQgciTQazD9gIAfKrWQ5Ni8jNs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-496-S_4x5xmwNNerxEPXImfMFQ-1; Wed, 19 Apr 2023 03:22:01 -0400 X-MC-Unique: S_4x5xmwNNerxEPXImfMFQ-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-3f173bd0fc9so12184965e9.3 for ; Wed, 19 Apr 2023 00:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681888920; x=1684480920; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FCCYf58WbiV7ZwiVXeHUCjynN8kwG+K1Gw0EryKxlNA=; b=cyiK29rUXH3e7kVgueA4xcvQRr4FygHRcxxwxTHxCAWZCt8Qy0ZtBBB6/+TYF+sdeC HTrVOc75RC2d5nrZ4DpIukVGJ7bb0iejzlqiF347JL8f8Li1EzWUnFmjTesqeODfP9jz MZ74h21Pc2+GFV66mtkeZw/Zw0ZkZs6PMJEJ5w8F+uDrCpIEaf35tgwejL5rk0tTlhtX z+3E7N6l/ce8HVrrTGMhmWBpkF7JgXF30c1F37XyHUj9uC80bie5dokeDBCXtxAlNPn4 dwDP8QshOrChstulHKfe9o9jdhexssLAlrC++1of5MAw5z6NSODDG6Fya5wd0PBHayS6 eLGQ== X-Gm-Message-State: AAQBX9eFzoT7FDRvHXPnqUW+2u1V22I9KbEfiXcBKIUwX2vOMafa+nAS 7TPOLRyi66Er0j9/d9zn/dOI8GlGMgvdG96UV6p2khr83NJFBtiYaofgsDNyG8Bc7pH5wJWQepu FEFgaT1IMyyzYXUBcJY11ZesO X-Received: by 2002:adf:ea4f:0:b0:2da:2aa0:13e8 with SMTP id j15-20020adfea4f000000b002da2aa013e8mr3873867wrn.26.1681888920569; Wed, 19 Apr 2023 00:22:00 -0700 (PDT) X-Google-Smtp-Source: AKy350aNwuzmpbvYRPHoSltgT3RyKQDrpmpgLNn+Tljmbr7T+NCiG+eylILlLmRgC0uK/hpojLTqCA== X-Received: by 2002:adf:ea4f:0:b0:2da:2aa0:13e8 with SMTP id j15-20020adfea4f000000b002da2aa013e8mr3873828wrn.26.1681888920083; Wed, 19 Apr 2023 00:22:00 -0700 (PDT) Received: from ?IPV6:2003:cb:c70b:7b00:7c52:a5fa:8004:96fd? (p200300cbc70b7b007c52a5fa800496fd.dip0.t-ipconnect.de. [2003:cb:c70b:7b00:7c52:a5fa:8004:96fd]) by smtp.gmail.com with ESMTPSA id s9-20020a5d6a89000000b002cf1c435afcsm15031069wru.11.2023.04.19.00.21.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Apr 2023 00:21:59 -0700 (PDT) Message-ID: <5869f50f-0858-ab0c-9049-4345abcf5641@redhat.com> Date: Wed, 19 Apr 2023 09:21:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Sean Christopherson Cc: Chao Peng , Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , wei.w.wang@intel.com, Mike Rapoport , Liam Merwick , Isaku Yamahata , Jarkko Sakkinen , Ackerley Tng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <658018f9-581c-7786-795a-85227c712be0@redhat.com> <1ed06a62-05a1-ebe6-7ac4-5b35ba272d13@redhat.com> <9efef45f-e9f4-18d1-0120-f0fc0961761c@redhat.com> Content-Language: en-US From: David Hildenbrand Organization: Red Hat Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19.04.23 02:47, Sean Christopherson wrote: > On Tue, Apr 18, 2023, David Hildenbrand wrote: >> On 17.04.23 21:16, Sean Christopherson wrote: >>> Hidden/Concealed/etc - Too close to secretmem, suffers the "hidden from whom" problem, >>> and depending on the use case, the memory may not actually be concealed from the >>> user that controls the VMM. >>> >>> Restricted - "rmem" collides with "reserved memory" in code. >>> >>> Guarded - Conflicts with s390's "guarded storage", has the "from whom" problem. >>> >>> Inaccessible - Many of the same problems as "hidden". >>> >>> Unmappable - Doesn't cover things like read/write, and is wrong in the sense that >>> the memory is still mappable, just not via mmap(). >>> >>> Secured - I'm not getting anywhere near this one :-) >> >> The think about "secretmem" that I kind-of like (a little) is that it >> explains what it's used for: storing secrets. We don't call it "unmapped" >> memory because we unmap it from the directmap or "unpinnable" memory or >> "inaccessible" memory ... or even "restricted" because it has restrictions >> ... how the secrets are protected is kind of an implementation detail. >> >> So instead of describing *why*/*how* restrictedmem is the weird kid >> (restricted/guarded/hidden/restricted/inaccessible/ ...), maybe rather >> describe what it's used for? >> >> I know, I know, "there are other use cases where it will be used outside of >> VM context". I really don't care. > > Heh, we originally proposed F_SEAL_GUEST, but that was also sub-optimal[1] ;-) > >> "memfd_vm" / "vm_mem" would be sooo (feel free to add some more o's here) >> much easier to get. It's a special fd to be used to back VM memory. Depending >> on the VM type (encrypted/protected/whatever), restrictions might apply (not >> able to mmap, not able to read/write ...). For example, there really is no >> need to disallow mmap/read/write when using that memory to back a simple VM >> where all we want to do is avoid user-space page tables. > > In seriousness, I do agree with Jason's very explicit objection[2] against naming > a non-KVM uAPI "guest", or any variation thereof. While I agree, it's all better than the naming we use right now ... Let me throw "tee_mem" / "memfd_tee" into the picture. That could eventually catch what we want to have. Or "coco_mem" / "memfd_coco". Of course, both expect that people know the terminology (just like what "vm" stands for), but it's IMHO significantly better than restricted/guarded/opaque/whatsoever. Again, expresses what it's used for, not why it behaves in weird ways. > > An alternative that we haven't considered since the very early days is making the > uAPI a KVM ioctl() instead of a memfd() flag or dedicated syscall. Looking at the > code for "pure shim" implementation[3], that's actually not that crazy of an idea. Yes. > > I don't know that I love the idea of burying this in KVM, but there are benefits > to coupling restrictedmem to KVM (aside from getting out from behind this bikeshed > that I created). Yes, it's all better than jumping through hoops to come up with a bad name like "restrictedmem". > > The big benefit is that the layer of indirection goes away. That simplifies things > like enhancing restrictedmem to allow host userspace access for debug purposes, > batching TLB flushes if a PUNCH_HOLE spans multiple memslots, enforcing exclusive > access, likely the whole "share with a device" story if/when we get there, etc. > > The obvious downsides are that (a) maintenance falls under the KVM umbrella, but > that's likely to be true in practice regardless of where the code lands, and Yes. > (b) if another use case comes along, e.g. the Gunyah hypervisor[4][5], we risk > someone reinventing a similar solution. I agree. But if it's as simple as providing an ioctl for that hypervisor that simply wires up the existing implementation, it's not too bad. > > If we can get Gunyah on board and they don't need substantial changes to the > restrictedmem implementation, then I'm all for continuing on the path we're on. > But if Gunyah wants to do their own thing, and the lightweight shim approach is > viable, then it's awfully tempting to put this all behind a KVM ioctl(). Right. Or we still succeed in finding a name that's not as bad as what we had so far. -- Thanks, David / dhildenb