linux-kernel - RE: [外部邮件] Re: [PATCH] virt/coco/sev-guest: Don't free decrypted 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3d379ec5fe19499ca456e1b842ddf3b5@baidu.com>
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