From: Dave Hansen <dave.hansen@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
Naveen N Rao <naveen@kernel.org>,
Dan Williams <dan.j.williams@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-coco@lists.linux.dev,
Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Vishal Annapurve <vannapurve@google.com>,
Kirill Shutemov <kirill.shutemov@linux.intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
Kevin Loughlin <kevinloughlin@google.com>
Subject: Re: [RFC PATCH] x86/sev: Disallow userspace access to BIOS region for SEV-SNP guests
Date: Tue, 8 Apr 2025 14:19:24 -0700 [thread overview]
Message-ID: <fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com> (raw)
In-Reply-To: <1bc4c506-57ad-38aa-d56d-ed058f54708e@amd.com>
On 4/8/25 06:43, Tom Lendacky wrote:
>> Tom/Boris, do you see a problem blocking access to /dev/mem for SEV
>> guests?
> Not sure why we would suddenly not allow that.
Both TDX and SEV-SNP have issues with allowing access to /dev/mem.
Disallowing access to the individually troublesome regions can fix
_part_ of the problem. But suddenly blocking access is guaranteed to fix
*ALL* the problems forever.
Or, maybe we just start returning 0's for all reads and throw away all
writes. That is probably less likely to break userspace that doesn't
know what it's doing in the first place.
next prev parent reply other threads:[~2025-04-08 21:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 12:02 [RFC PATCH] x86/sev: Disallow userspace access to BIOS region for SEV-SNP guests Naveen N Rao (AMD)
2025-04-03 19:06 ` Dan Williams
2025-04-07 13:13 ` Naveen N Rao
2025-04-08 13:43 ` Tom Lendacky
2025-04-08 21:19 ` Dave Hansen [this message]
2025-04-08 23:55 ` Dan Williams
2025-04-09 16:02 ` Nikolay Borisov
2025-04-09 17:06 ` Dan Williams
2025-04-09 17:39 ` Kees Cook
2025-04-09 18:39 ` Dan Williams
2025-04-10 12:03 ` Nikolay Borisov
2025-04-10 16:32 ` Kees Cook
2025-04-10 16:39 ` Nikolay Borisov
2025-04-10 19:20 ` Dan Williams
2025-04-10 19:27 ` Nikolay Borisov
2025-04-10 20:07 ` Dan Williams
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=fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kevinloughlin@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=naveen@kernel.org \
--cc=nik.borisov@suse.com \
--cc=thomas.lendacky@amd.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