From: Nikolay Borisov <nik.borisov@suse.com>
To: Dan Williams <dan.j.williams@intel.com>, dave.hansen@linux.intel.com
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>,
Vishal Annapurve <vannapurve@google.com>,
Kees Cook <keescook@chromium.org>,
stable@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] Restrict devmem for confidential VMs
Date: Mon, 14 Apr 2025 13:56:21 +0300 [thread overview]
Message-ID: <0df1ea92-4386-4237-bf98-02503a5829ba@suse.com> (raw)
In-Reply-To: <174433453526.924142.15494575917593543330.stgit@dwillia2-xfh.jf.intel.com>
On 11.04.25 г. 4:22 ч., Dan Williams wrote:
> Changes since v1 [1]:
> * Fix the fact that devmem_is_allowed() == 2 does not prevent
> mmap access (Kees)
> * Rather than teach devmem_is_allowed() == 2 to map zero pages in the
> mmap case, just fail (Nikolay)
>
> [1]: http://lore.kernel.org/67f5b75c37143_71fe2949b@dwillia2-xfh.jf.intel.com.notmuch
>
> ---
> The story starts with Nikolay reporting an SEPT violation due to
> mismatched encrypted/non-encrypted mappings of the BIOS data space [2].
>
> An initial suggestion to just make sure that the BIOS data space is
> mapped consistently [3] ran into another issue that TDX and SEV-SNP
> disagree about when that space can be mapped as encrypted.
>
> Then, in response to a partial patch to allow SEV-SNP to block BIOS data
> space for other reasons [4], Dave asked why not just give up on /dev/mem
> access entirely in the confidential VM case [5].
>
> Enter this series to:
>
> 1/ Close a subtle hole whereby /dev/mem that is supposed return zeros in
> lieu of access only enforces that for read()/write()
>
> 2/ Use that new closed hole to reliably disable all /dev/mem access for
> confidential x86 VMs
>
> [2]: http://lore.kernel.org/20250318113604.297726-1-nik.borisov@suse.com
> [3]: http://lore.kernel.org/174346288005.2166708.14425674491111625620.stgit@dwillia2-xfh.jf.intel.com
> [4]: http://lore.kernel.org/20250403120228.2344377-1-naveen@kernel.org
> [5]: http://lore.kernel.org/fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com
> ---
>
> Dan Williams (3):
> x86/devmem: Remove duplicate range_is_allowed() definition
> devmem: Block mmap access when read/write access is restricted
> x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default
>
>
> arch/x86/Kconfig | 2 ++
> arch/x86/include/asm/x86_init.h | 2 ++
> arch/x86/kernel/x86_init.c | 6 ++++++
> arch/x86/mm/init.c | 23 +++++++++++++++++------
> arch/x86/mm/pat/memtype.c | 31 ++++---------------------------
> drivers/char/mem.c | 18 ------------------
> include/linux/io.h | 26 ++++++++++++++++++++++++++
> 7 files changed, 57 insertions(+), 51 deletions(-)
>
> base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
prev parent reply other threads:[~2025-04-14 10:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 1:22 Dan Williams
2025-04-11 1:22 ` [PATCH v2 1/3] x86/devmem: Remove duplicate range_is_allowed() definition Dan Williams
2025-04-14 18:17 ` Naveen N Rao
2025-04-16 21:25 ` Dan Williams
2025-04-17 7:28 ` Naveen N Rao
2025-04-17 18:27 ` Dan Williams
2025-04-19 9:09 ` Naveen N Rao
2025-04-11 1:22 ` [PATCH v2 2/3] devmem: Block mmap access when read/write access is restricted Dan Williams
2025-04-11 2:32 ` Kees Cook
2025-04-11 4:59 ` Dan Williams
2025-04-11 15:38 ` Dave Hansen
2025-04-11 21:48 ` Dan Williams
2025-04-11 1:22 ` [PATCH v2 3/3] x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default Dan Williams
2025-04-14 18:22 ` Naveen N Rao
2025-04-16 21:30 ` Dan Williams
2025-04-14 10:56 ` Nikolay Borisov [this message]
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=0df1ea92-4386-4237-bf98-02503a5829ba@suse.com \
--to=nik.borisov@suse.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=stable@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
all inboxes | Powered by JetHome®