From: Dave Hansen <dave.hansen@intel.com>
To: Nikolay Borisov <nik.borisov@suse.com>, 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
Subject: Re: [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest
Date: Tue, 18 Mar 2025 07:48:50 -0700 [thread overview]
Message-ID: <babd4e40-0cb6-4796-af86-1944e32f89ee@intel.com> (raw)
In-Reply-To: <20250318113604.297726-1-nik.borisov@suse.com>
On 3/18/25 04:36, Nikolay Borisov wrote:
> 1. Should we forbid getting a descriptor to /dev/mem (this patch)
> 2. Skip creating /dev/mem altogether3
Like Kirill mentioned, it would be nice to leverage the existing hooks:
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
rc = security_locked_down(LOCKDOWN_DEV_MEM);
if (rc)
return rc;
Lockdown seems like a decent fit. We'd also ideally check
lockdown_is_locked_down() in x86 code and spew epithets if someone is
booting a CoCo guest without lockdown.
> 3. Possibly tinker with internals of ioremap to ensure that no memory which is
> backed by kvm memslots is remapped as shared.
It's not just memslots, though. It's any TDX private memory which
includes stuff the TDX module uses like the PAMT or SEPT pages.
next prev parent reply other threads:[~2025-03-18 14:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 11:36 [RFC PATCH] /dev/mem: Disable /dev/mem under TDX guest Nikolay Borisov
2025-03-18 11:53 ` 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 [this message]
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=babd4e40-0cb6-4796-af86-1944e32f89ee@intel.com \
--to=dave.hansen@intel.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=nik.borisov@suse.com \
--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