From: Dave Hansen <dave.hansen@intel.com>
To: Dan Williams <dan.j.williams@intel.com>, dave.hansen@linux.intel.com
Cc: x86@kernel.org, Kees Cook <kees@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Naveen N Rao <naveen@kernel.org>,
Vishal Annapurve <vannapurve@google.com>,
Kirill Shutemov <kirill.shutemov@linux.intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
stable@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] x86/devmem: Drop /dev/mem access for confidential guests
Date: Mon, 28 Apr 2025 08:53:47 -0700 [thread overview]
Message-ID: <9a4b347f-9a18-4578-9031-0d1bc98e668d@intel.com> (raw)
In-Reply-To: <174500659632.1583227.11220240508166521765.stgit@dwillia2-xfh.jf.intel.com>
On 4/18/25 13:04, Dan Williams wrote:
> Nikolay reports [1] that accessing BIOS data (first 1MB of the physical
> address space) via /dev/mem results in an SEPT violation.
Would most developers reading this know what an "SEPT violation" is or
what its implications are?
This results in an immediate exit from and termination of the TDX guest,
right?
next prev parent reply other threads:[~2025-04-28 15:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 19:11 [PATCH v3 0/2] Restrict devmem for confidential VMs Dan Williams
2025-04-17 19:12 ` [PATCH v3 1/2] x86/devmem: Remove duplicate range_is_allowed() definition Dan Williams
2025-04-17 19:30 ` Dave Hansen
2025-04-17 19:12 ` [PATCH v3 2/2] x86/devmem: Drop /dev/mem access for confidential guests Dan Williams
2025-04-17 19:33 ` Dave Hansen
2025-04-17 22:31 ` kernel test robot
2025-04-17 23:24 ` kernel test robot
2025-04-18 20:04 ` [PATCH v4 " Dan Williams
2025-04-22 13:38 ` Nikolay Borisov
2025-04-23 17:18 ` Naveen N Rao
2025-04-23 20:36 ` Dan Williams
2025-04-24 6:35 ` Naveen N Rao
2025-04-28 15:53 ` Dave Hansen [this message]
2025-04-28 16:30 ` Jianxiong Gao
2025-04-28 16:36 ` Dave Hansen
2025-05-07 5:44 ` [PATCH v3 " kernel test robot
2025-04-22 14:09 ` [PATCH v3 0/2] Restrict devmem for confidential VMs Nikolay Borisov
2025-04-28 15:50 ` Dave Hansen
2025-04-28 22:48 ` Dan Williams
2025-04-29 0:37 ` Dave Hansen
2025-04-30 15:41 ` Suzuki K Poulose
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=9a4b347f-9a18-4578-9031-0d1bc98e668d@intel.com \
--to=dave.hansen@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kees@kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=naveen@kernel.org \
--cc=nik.borisov@suse.com \
--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;
as well as URLs for NNTP newsgroup(s).