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: <7bd627df-0303-4ded-b8c8-ceb84fb20f0d@amazon.com>
Date: Fri, 1 Nov 2024 09:56:12 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <dave.hansen@...el.com>
CC: <ackerleytng@...gle.com>, <agordeev@...ux.ibm.com>,
	<aou@...s.berkeley.edu>, <borntraeger@...ux.ibm.com>, <bp@...en8.de>,
	<catalin.marinas@....com>, <chenhuacai@...nel.org>, <corbet@....net>,
	<dave.hansen@...ux.intel.com>, <david@...hat.com>, <derekmn@...zon.com>,
	<gerald.schaefer@...ux.ibm.com>, <gor@...ux.ibm.com>, <graf@...zon.com>,
	<hca@...ux.ibm.com>, <hpa@...or.com>, <jgowans@...zon.com>,
	<jthoughton@...gle.com>, <kalyazin@...zon.com>, <kernel@...0n.name>,
	<kvm@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-kselftest@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-riscv@...ts.infradead.org>, <linux-s390@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>, <loongarch@...ts.linux.dev>,
	<luto@...nel.org>, <mathieu.desnoyers@...icios.com>, <mhiramat@...nel.org>,
	<mingo@...hat.com>, <palmer@...belt.com>, <paul.walmsley@...ive.com>,
	<pbonzini@...hat.com>, <peterz@...radead.org>, <quic_eberman@...cinc.com>,
	<rostedt@...dmis.org>, <roypat@...zon.co.uk>, <rppt@...nel.org>,
	<seanjc@...gle.com>, <shuah@...nel.org>, <svens@...ux.ibm.com>,
	<tabba@...gle.com>, <tglx@...utronix.de>, <vannapurve@...gle.com>,
	<will@...nel.org>, <x86@...nel.org>, <xmarcalx@...zon.com>,
	<mlipp@...zon.at>, <canellac@...zon.at>, <elena.reshetova@...el.com>
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?

> If the attack is mitigated when the > data is _mapped_, then it's
> certainly not possible _unmapped_.
>
> So why bother with direct map removal for TDX?  A VMM write to TD
> private data causes machine checks.  So any kernel bug that even
> accidentally writes to kernel memory can bring the whole system down.
> Not nice.

Fair enough. It hasn't been clear to me if there is a machine check when
the host kernel accesses guest memory only transiently. I was assuming
there is not. But if other mitigations completely prevent even
speculative access of TD private memory like you're saying, then agree
nothing to gain from direct map removal in the TDX case.

Derek


[2] https://download.vusec.net/papers/quarantine_raid23.pdf