linux-kernel - Re: [RFC RFT PATCH 1/4] hv: Leak pages if set_memory

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]

Date: Fri, 1 Mar 2024 19:13:23 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
	"mhklinux@...look.com" <mhklinux@...look.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "davem@...emloft.net" <davem@...emloft.net>,
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kys@...rosoft.com" <kys@...rosoft.com>,
	"Cui, Dexuan" <decui@...rosoft.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
CC: "sathyanarayanan.kuppuswamy@...ux.intel.com"
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, "Reshetova, Elena"
	<elena.reshetova@...el.com>
Subject: Re: [RFC RFT PATCH 1/4] hv: Leak pages if set_memory_encrypted()
 fails

On Fri, 2024-03-01 at 19:00 +0000, Michael Kelley wrote:
> From: Rick Edgecombe <rick.p.edgecombe@...el.com> Sent: Wednesday,
> February 21, 2024 6:10 PM
> > 
> 
> Historically, the preferred Subject prefix for changes to
> connection.c has
> been "Drivers: hv: vmbus:", not just "hv:".  Sometimes that
> preference
> isn't followed, but most of the time it is.

Ok, I can update it.

> 
> > On TDX it is possible for the untrusted host to cause
> 
> I'd argue that this is for CoCo VMs in general, not just TDX.  I
> don't know
> all the failure modes for SEV-SNP, but the code paths you are
> changing
> are run in both TDX and SEV-SNP CoCo VMs.

On SEV-SNP the host can cause the call to fail too was my
understanding. But in Linux, that side panics and never gets to the
point of being able to free the shared memory. So it's not TDX
architecture specific, it's just how Linux handles it on the different
sids. For TDX the suggestion was to avoid panicing because it is
possible to handle in SW, as Linux usually tries it's best to do.

> 
> > set_memory_encrypted() or set_memory_decrypted() to fail such that
> > an
> > error is returned and the resulting memory is shared. Callers need
> > to take
> > care to handle these errors to avoid returning decrypted (shared)
> > memory to
> > the page allocator, which could lead to functional or security
> > issues.
> > 
> > Hyperv could free decrypted/shared pages if set_memory_encrypted()
> > fails.
> 
> It's not Hyper-V doing the freeing.  Maybe say "VMBus code could
> free ...."

Ok.