From: "Gupta, Pankaj" <pankaj.gupta@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Punit Salian <psalian@google.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Stefan Hajnoczi <stefanha@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
linux-coco@lists.linux.dev, x86@kernel.org
Subject: Re: [PATCH] fuse: mark DAX VMA page protections as decrypted
Date: Tue, 18 Aug 2026 18:00:27 +0200 [thread overview]
Message-ID: <004afd12-762d-45d6-ab75-037d58e7a359@amd.com> (raw)
In-Reply-To: <909ab2ef-b931-4a64-acfc-13096f232a07@amd.com>
>>> In confidential computing guest environments (such as AMD SEV-SNP or
>>> Intel TDX), direct memory access (DAX) mappings between the guest kernel
>>> and host-backed FUSE/virtiofs shared memory regions must be accessed
>>> using shared (decrypted) page protections.
>>>
>>> Modify fuse_dax_mmap() to apply pgprot_decrypted() to vma->vm_page_prot
>>> when establishing FUSE DAX memory mappings. This ensures guest page
>>> table entries for shared DAX buffers are explicitly marked as decrypted,
>>> preventing memory encryption faults when accessing host-shared DAX memory.
>>>
>>> Signed-off-by: Punit Salian <psalian@google.com>
>>> ---
>>> fs/fuse/dax.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
>>> index a15c464c8d19..00e316a7f805 100644
>>> --- a/fs/fuse/dax.c
>>> +++ b/fs/fuse/dax.c
>>> @@ -826,6 +826,7 @@ int fuse_dax_mmap(struct file *file, struct vm_area_struct *vma)
>>> file_accessed(file);
>>> vma->vm_ops = &fuse_dax_vm_ops;
>>> vm_flags_set(vma, VM_MIXEDMAP | VM_HUGEPAGE);
>>> + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
For virtio-pmem on host with SEV support we addressed similar issue by
marking FS DAX device memory decrypted in memremap_pages()
(commit 867400af90f1, "mm/memremap.c: map FS_DAX device memory as
decrypted"), since the device memory
is mapped though the kernel address space there. For virtio-fs DAX we
don't seem to have such a central location so
VMA level handling seems reasonable fix to me.
That said, I'm not entirely certain about all of the security
implications in a CoCo environment, given that the host is generally
considered untrusted
and virtio-fs involves sharing host-backed memory with the guest. Till
we get some mechanism to access this memory as encrypted, we can have
this support
with existing security practices for virtio-fs:
Acked-by: Pankaj Gupta <pankaj.gupta@amd.com>
next prev parent reply other threads:[~2026-08-18 16:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 21:07 [PATCH] fuse: mark DAX VMA page protections as decrypted Punit Salian
2026-08-18 11:38 ` Miklos Szeredi
2026-08-18 13:42 ` Tom Lendacky
2026-08-18 16:00 ` Gupta, Pankaj [this message]
2026-08-19 15:03 ` Gupta, Pankaj
2026-08-19 16:48 ` Punit Salian
2026-08-19 18:16 ` Michael Roth
2026-08-20 8:21 ` Gupta, Pankaj
2026-08-24 17:58 ` Punit Salian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=004afd12-762d-45d6-ab75-037d58e7a359@amd.com \
--to=pankaj.gupta@amd.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=psalian@google.com \
--cc=stefanha@redhat.com \
--cc=thomas.lendacky@amd.com \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.