From: Nikolay Borisov <nik.borisov@suse.com>
To: dave.hansen@linux.intel.com
Cc: kirill.shutemov@linux.intel.com, linux-coco@lists.linux.dev,
x86@kernel.org, linux-kernel@vger.kernel.org,
vannapurve@google.com, Nikolay Borisov <nik.borisov@suse.com>
Subject: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest
Date: Tue, 18 Mar 2025 13:36:04 +0200 [thread overview]
Message-ID: <20250318113604.297726-1-nik.borisov@suse.com> (raw)
If a piece of memory is read from /dev/mem that falls outside of the
System Ram region i.e bios data region the kernel creates a shared
mapping via xlate_dev_mem_ptr() (this behavior was introduced by
9aa6ea69852c ("x86/tdx: Make pages shared in ioremap()"). This results
in a region having both a shared and a private mapping.
Subsequent accesses to this region via the private mapping induce a
SEPT violation and a crash of the VMM. In this particular case the
scenario was a userspace process reading something from the bios data
area at address 0x497 which creates a shared mapping, and a followup
reboot accessing __va(0x472) which access pfn 0 via the private mapping
causing mayhem.
Fix this by simply forbidding access to /dev/mem when running as an TDX
guest.
Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
Sending this now to hopefully spur up discussion as to how to handle the described
scenario. This was hit on the GCP cloud and was causing their hypervisor to crash.
I guess the most pressing question is what will be the most sensible approach to
eliminate such situations happening in the future:
1. Should we forbid getting a descriptor to /dev/mem (this patch)
2. Skip creating /dev/mem altogether3
3. Possibly tinker with internals of ioremap to ensure that no memory which is
backed by kvm memslots is remapped as shared.
4. Eliminate the access to 0x472 from the x86 reboot path, after all we don't
really have a proper bios at that address.
5. Something else ?
arch/x86/coco/tdx/tdx.c | 4 ++++
drivers/char/mem.c | 3 +++
include/linux/security.h | 6 ++++++
3 files changed, 13 insertions(+)
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index 32809a06dab4..615e8a300fc7 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -40,6 +40,8 @@
static atomic_long_t nr_shared;
+bool devmem_disabled = false;
+
/* Called from __tdx_hypercall() for unrecoverable failure */
noinstr void __noreturn __tdx_hypercall_failed(void)
{
@@ -1063,6 +1065,8 @@ void __init tdx_early_init(void)
setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
+ devmem_disabled = true;
+
/* TSC is the only reliable clock in TDX guest */
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 169eed162a7f..8778d46216f2 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -616,6 +616,9 @@ static int open_port(struct inode *inode, struct file *filp)
if (iminor(inode) != DEVMEM_MINOR)
return 0;
+ if (devmem_disabled)
+ return -EINVAL;
+
/*
* Use a unified address space to have a single point to manage
* revocations when drivers want to take over a /dev/mem mapped
diff --git a/include/linux/security.h b/include/linux/security.h
index 980b6c207cad..1757f683a09d 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -265,6 +265,12 @@ struct request_sock;
#define LSM_UNSAFE_PTRACE 2
#define LSM_UNSAFE_NO_NEW_PRIVS 4
+#ifdef CONFIG_INTEL_TDX_GUEST
+extern bool devmem_disabled;
+#else
+#define devmem_disabled 0
+#endif
+
#ifdef CONFIG_MMU
extern int mmap_min_addr_handler(const struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos);
--
2.43.0
next reply other threads:[~2025-03-18 11:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 11:36 Nikolay Borisov [this message]
2025-03-18 11:53 ` [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest Juergen Gross
2025-03-18 11:56 ` Nikolay Borisov
2025-03-18 12:23 ` Kirill A. Shutemov
2025-03-18 12:53 ` Nikolay Borisov
2025-03-18 13:27 ` Kirill A. Shutemov
2025-03-18 14:21 ` Nikolay Borisov
2025-03-20 9:38 ` Kirill A. Shutemov
2025-03-18 14:48 ` Dave Hansen
2025-03-18 17:56 ` Nikolay Borisov
2025-03-18 19:06 ` Dan Williams
2025-03-24 9:59 ` Nikolay Borisov
2025-03-25 18:16 ` Dan Williams
2025-03-28 10:51 ` Nikolay Borisov
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=20250318113604.297726-1-nik.borisov@suse.com \
--to=nik.borisov@suse.com \
--cc=dave.hansen@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=vannapurve@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox