mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [外部邮件] Re: [PATCH] virt/coco/sev-guest: Don't free decrypted memory
Date: Tue, 18 Jun 2024 08:53:37 +0000	[thread overview]
Message-ID: <3d379ec5fe19499ca456e1b842ddf3b5@baidu.com> (raw)
In-Reply-To: <a5326e77-bb19-a92f-6beb-7d2c64866891@amd.com>

> 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

      reply	other threads:[~2024-06-18  8:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14  5:10 Li RongQing
2024-06-14 16:08 ` Tom Lendacky
2024-06-18  8:53   ` Li,Rongqing [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d379ec5fe19499ca456e1b842ddf3b5@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®