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

["Reshetova, Elena" <elena.reshetova@intel.com>]

> 
> +Elena
> 
> On 2024-11-01 at 16:06+0000, Dave Hansen wrote:
> > On 10/31/24 17:10, Manwaring, Derek wrote:
> > > 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.
> 
> > The main thing I think you want to keep in mind is mentioned in the "TDX
> > Module v1.5 Base Architecture Specification"[1]:
> >
> > > 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.