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: <78da25c9160612bc60bb1b421a0226e4368db51a.camel@intel.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ