Thread (36 messages) 36 messages, 9 authors, 2024-11-15

RE: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

From: "Reshetova, Elena" <elena.reshetova@intel.com>
Date: 2024-11-04 08:33:21
Also in: kvm, linux-doc, linux-kselftest, linux-mm, linux-riscv, linux-s390, lkml, loongarch

+Elena

On 2024-11-01 at 16:06+0000, Dave Hansen wrote:
quoted
On 10/31/24 17:10, Manwaring, Derek wrote:
quoted
TDX and SEV encryption happens between the core and main memory, so
cached guest data we're most concerned about for transient execution
attacks isn't necessarily inaccessible.

I'd be interested what Intel, AMD, and other folks think on this, but I
think direct map removal is worthwhile for CoCo cases as well.
I'm not sure specifically which attacks you have in mind.  [...]

I _think_ you might be thinking of attacks like MDS where some random
microarchitectural buffer contains guest data after a VM exit and then
an attacker extracts it.  Direct map removal doesn't affect these
buffers and doesn't mitigate an attacker getting the data out.
Right, the only attacks we can thwart with direct map removal are
transient execution attacks on the host kernel whose leak origin is
"Mapped memory" in Table 1 of the Quarantine paper [2]. Maybe the
simplest hypothetical to consider here is a new spectre v1 gadget in the
host kernel.
quoted
The main thing I think you want to keep in mind is mentioned in the "TDX
Module v1.5 Base Architecture Specification"[1]:
quoted
Any software except guest TD or TDX module must not be able to
speculatively or non-speculatively access TD private memory,
That's a pretty broad claim and it involves mitigations in hardware and
the TDX module.

1. https://cdrdv2.intel.com/v1/dl/getContent/733575
Thank you, I hadn't seen that. That is a very strong claim as far as
preventing speculative access; I didn't realize Intel claimed that about
TDX. The comma followed by "to detect if a prior corruption attempt was
successful" makes me wonder a bit if the statement is not quite as broad
as it sounds, but maybe that's just meant to relate it to the integrity
section?
This statement *is* for integrity section. We have a separate TDX guidance
on side-channels (including speculative) [3] and some speculative attacks
that affect confidentiality (for example spectre v1) are listed as not covered
by TDX but remaining SW responsibility (as they are now). 

[3] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-domain-security-guidance-for-developers.html

Best Regards,
Elena.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help