linux-kernel - Re: [RFC PATCH v2 1/2] KVM: guest_memfd: add generic population via write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <03530f39-8abe-4c24-b5a8-3b6f91eb1c74@amd.com>
Date: Tue, 3 Dec 2024 08:55:59 -0600
From: Mike Day <michael.day@....com>
To: Nikita Kalyazin <kalyazin@...zon.com>, pbonzini@...hat.com,
 shuah@...nel.org, kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, david@...hat.com, quic_eberman@...cinc.com,
 jthoughton@...gle.com, brijesh.singh@....com, michael.roth@....com,
 graf@...zon.de, jgowans@...zon.com, roypat@...zon.co.uk, derekmn@...zon.com,
 nsaenz@...zon.es, xmarcalx@...zon.com
Subject: Re: [RFC PATCH v2 1/2] KVM: guest_memfd: add generic population via
 write

On 11/29/24 06:39, Nikita Kalyazin wrote:
>   
> +#if defined(CONFIG_KVM_GENERIC_PRIVATE_MEM) && !defined(CONFIG_KVM_AMD_SEV)

Another option is to use the confidential computing (coco) attributes to keep
the write operation limited to clear-text guests (diff against patch 1/2):
There are a couple of benefits and shortcomings that I've listed below the diff.

diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 9aba0ba25276..b7a0c7f2f82d 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0
  #include <linux/backing-dev.h>
+#include <linux/cc_platform.h>
  #include <linux/falloc.h>
  #include <linux/kvm_host.h>
  #include <linux/pagemap.h>
@@ -274,7 +275,14 @@ static struct folio *kvm_gmem_get_folio(struct inode *inode, pgoff_t index)
         return filemap_grab_folio(inode->i_mapping, index);
  }

-#if defined(CONFIG_KVM_GENERIC_PRIVATE_MEM) && !defined(CONFIG_KVM_AMD_SEV)
+static bool kvm_has_cc(void)
+{
+       if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
+               return true;
+       return false;
+}
+
+#if defined(CONFIG_KVM_GENERIC_PRIVATE_MEM)
  static ssize_t kvm_kmem_gmem_write(struct file *file, const char __user *buf,
                                    size_t count, loff_t *offset)
  {
@@ -290,6 +298,9 @@ static ssize_t kvm_kmem_gmem_write(struct file *file, const char __user *buf,
         if (!buf)
                 return -EINVAL;

+       if (kvm_has_cc())
+               return -EIO;
+
         start = *offset >> PAGE_SHIFT;
          end = (*offset + count) >> PAGE_SHIFT;

@@ -564,7 +575,7 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn)
  }

  static struct file_operations kvm_gmem_fops = {
-#if defined(CONFIG_KVM_GENERIC_PRIVATE_MEM) && !defined(CONFIG_KVM_AMD_SEV)
+#if defined(CONFIG_KVM_GENERIC_PRIVATE_MEM)
         .llseek         = default_llseek,
         .write          = kvm_kmem_gmem_write,
  #endif

Advantages:
  * works with multiple architectures (powerpc and x86 so far)
  * enumerates specific types of coco attributes

Disadvantages:
  * The platform can have an encryption attribute but still be running a guest in clear text
  * Some guests could be encrypted while others are clear text

To remedy the disadvantage, the write function would need to check if guest encryption is
currently active for a specific guest.

Mike

> +static ssize_t kvm_kmem_gmem_write(struct file *file, const char __user *buf,
> +				   size_t count, loff_t *offset)
> +{
> +	pgoff_t start, end, index;
> +	ssize_t ret = 0;