linux-kernel - RE: [RFC PATCH v3 0/6] Direct Map Removal for guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB57509ED04CB0730680735AC9E7512@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Mon, 4 Nov 2024 08:33:06 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Manwaring, Derek" <derekmn@...zon.com>, "Hansen, Dave"
	<dave.hansen@...el.com>
CC: "ackerleytng@...gle.com" <ackerleytng@...gle.com>,
	"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>, "aou@...s.berkeley.edu"
	<aou@...s.berkeley.edu>, "borntraeger@...ux.ibm.com"
	<borntraeger@...ux.ibm.com>, "bp@...en8.de" <bp@...en8.de>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "chenhuacai@...nel.org"
	<chenhuacai@...nel.org>, "corbet@....net" <corbet@....net>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"david@...hat.com" <david@...hat.com>, "gerald.schaefer@...ux.ibm.com"
	<gerald.schaefer@...ux.ibm.com>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
	"Graf, Alexander" <graf@...zon.com>, "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
	"hpa@...or.com" <hpa@...or.com>, "jgowans@...zon.com" <jgowans@...zon.com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "kalyazin@...zon.com"
	<kalyazin@...zon.com>, "kernel@...0n.name" <kernel@...0n.name>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "luto@...nel.org"
	<luto@...nel.org>, "mathieu.desnoyers@...icios.com"
	<mathieu.desnoyers@...icios.com>, "mhiramat@...nel.org"
	<mhiramat@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"palmer@...belt.com" <palmer@...belt.com>, "paul.walmsley@...ive.com"
	<paul.walmsley@...ive.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	"roypat@...zon.co.uk" <roypat@...zon.co.uk>, "rppt@...nel.org"
	<rppt@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"shuah@...nel.org" <shuah@...nel.org>, "svens@...ux.ibm.com"
	<svens@...ux.ibm.com>, "tabba@...gle.com" <tabba@...gle.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "will@...nel.org" <will@...nel.org>,
	"x86@...nel.org" <x86@...nel.org>, "xmarcalx@...zon.com"
	<xmarcalx@...zon.com>, "mlipp@...zon.at" <mlipp@...zon.at>,
	"canellac@...zon.at" <canellac@...zon.at>
Subject: RE: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

> 
> +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.