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] [day] [month] [year] [list]
Date: Tue, 18 Jun 2024 08:53:37 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: Tom Lendacky <thomas.lendacky@....com>, "dan.j.williams@...el.com"
	<dan.j.williams@...el.com>, "bp@...en8.de" <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [外部邮件] Re: [PATCH] virt/coco/sev-guest: Don't free decrypted memory

> On 6/14/24 00:10, Li RongQing wrote:
> > In CoCo VMs, it is possible for the untrusted host to cause
> > set_memory_decrypted() to fail such that an error is returned and the
> > resulting memory is shared. Callers need to take care
> 
> Can you explain how it would fail or where in the call path it would fail?
> Are you referring to the the Page State Change being performed by the host but
> it returns a failure?
> 
> As long as the encryption bit hasn't been cleared in any of the guest pagetables
> for the page range, then there should not be an issue. When the page is
> referenced it will generate a #NPF and the host will have to make that page a
> private page in order for forward progress to be made. But, that page will
> already have been PVALIDATEd previously, so the resulting #VC for the page no
> longer being PVALIDATEd will allow the guest to detect the malicious hypervisor
> and terminate.
> 
> If we fail during the __change_page_attr_set_clr() call and we get a mix of
> pagetable entries that could be a problem, so leaking the pages would be best in
> that case.
> 
> And since the failure reason isn't clear after the call, leaking the pages is
> probably the safest thing.


your explanation is very clear ; I will rewrite this changelog

thank you very much,

-Li

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ