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 07BAFC77B7C for ; Wed, 19 Apr 2023 00:50:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231667AbjDSArU (ORCPT ); Tue, 18 Apr 2023 20:47:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231223AbjDSArS (ORCPT ); Tue, 18 Apr 2023 20:47:18 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A93F40CA for ; Tue, 18 Apr 2023 17:47:17 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-518d6f87a47so1401268a12.3 for ; Tue, 18 Apr 2023 17:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681865237; x=1684457237; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=BRhcoVi/so3GxRYGQIv2yienH23nZKhTwyow1BK26mo=; b=0vXk1nY8ogZSypVY8teXSisTQuRy9oa55TJG/XiVrwj+u/Qo0vg3WbKd21sInPPM2p 2U8Ei744fYmWLekeuuqaQsfez5jYqrAmEtKYgF+hkdk0BNLxQZ2mFVoTeI/V/6dulELE NRtiyHOwatu0hPGrB2/VfmAVe7Zk2QYvzKeoXk0yT3aq44f5Gny2xFGOtnRivD1NmiEz MlJoyTup23WZKtf5Vz6YKH7BkJVmFDJM2Vc3sXBfYdlN6rev3D4m1x5QfVjDolxiMTTW aqVFmUhXajY9bcrElrubMdPq2YIq1Vsd8ZMsXi7TdlCfVdE8/GHcxz2w7x2TBJgc3dFQ SXZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681865237; x=1684457237; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BRhcoVi/so3GxRYGQIv2yienH23nZKhTwyow1BK26mo=; b=XgGu4QfhTPKKfvF24/bD7GEb+skQX5IHy98gqy4OSX7xTPyr4IXfmeGT0RWtwobNsR KvSEuPqRjWkDkd2kSSLMEXB/xRbpOCRIRf4jvoDObseL86qp/I7wQ65qrYuq+k9reHku ZuAsT172Ko+HLHP3k+aGZKAkpfbWNNUWdU76LKJ8uyVaCtMEqWFKZds7xpFriZrubySR E601ISBfLhJWsaP15IupuQnHzFpeizkzMmUuQPuB+Q0Yet+KT6EJ6NKjUFzkFbr/3fmh IldAj2A3wxReUHHrhw7eVyjzBkhs+6e5Ox/PFd5JWIf7/BXhELLOqy+RWDqkxEP/QHGX /a3w== X-Gm-Message-State: AAQBX9c4VCZx+WQbtA+3VnAvChowzA0QYe5dtyJc1/yXQduRZdvdnlcQ XgkMkf8KlnwTCgCM8oI+7K2ACO08DvI= X-Google-Smtp-Source: AKy350at1UBX8RD7TMmqZ3VQjXQyrzp8DYlR0Mth2xOZ9GL7wA8Om61yEwOahqy7ThjKW9iBOw41knqnMxY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:1251:b0:1a5:255d:efcc with SMTP id u17-20020a170903125100b001a5255defccmr1485258plh.13.1681865236871; Tue, 18 Apr 2023 17:47:16 -0700 (PDT) Date: Tue, 18 Apr 2023 17:47:15 -0700 In-Reply-To: <9efef45f-e9f4-18d1-0120-f0fc0961761c@redhat.com> Mime-Version: 1.0 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> Message-ID: Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) From: Sean Christopherson To: David Hildenbrand 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 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. 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). 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 (b) if another use case comes along, e.g. the Gunyah hypervisor[4][5], we risk someone reinventing a similar solution. 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(). [1] https://lore.kernel.org/all/df11d753-6242-8f7c-cb04-c095f68b41fa@redhat.com [2] https://lore.kernel.org/all/20211123171723.GD5112@ziepe.ca [3] https://lore.kernel.org/all/ZDiCG%2F7OgDI0SwMR@google.com [4] https://lore.kernel.org/all/Y%2FkI66qQFJJ6bkTq@google.com [5] https://lore.kernel.org/all/20230304010632.2127470-13-quic_eberman@quicinc.com