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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM8PR11MB57505F62D149EF153F89B8BAE75D2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Fri, 8 Nov 2024 10:36:42 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Manwaring, Derek" <derekmn@...zon.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>,
	"canellac@...zon.at" <canellac@...zon.at>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"corbet@....net" <corbet@....net>, "Hansen, Dave" <dave.hansen@...el.com>,
	"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>,
	"mlipp@...zon.at" <mlipp@...zon.at>, "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>
Subject: RE: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

 
> On 2024-11-04 at 08:33+0000, Elena Reshetova wrote:
> > 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).
> 
> Thanks for the additional info, Elena. Given that clarification, I
> definitely see direct map removal and TDX as complementary.

Jus to clarify to make sure my comment is not misunderstood.
What I meant is that we cannot generally assume that confidentiality
leaks from CoCo guests to host/VMM via speculative channels
are completely impossible. Spectre V1 is a prime example of such a
possible leak. Dave also elaborated on other potential vectors earlier.

The usefulness of direct map removal for CoCo guests as a concrete
mitigation for certain types of memory attacks must be precisely
evaluated per each attack vector, attack vector direction (host -> guest,
guest ->host, etc) and per each countermeasure that CoCo vendors
provide for each such case. I don't know if there is any existing study
that examines this for major CoCo vendors. I think this is what must
be done for this work in order to have a strong reasoning for its usefulness.

Best Regards,
Elena.