All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Rödel" <jroedel@suse.de>
To: Jon Lange <jlange@microsoft.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"amd-sev-snp@lists.suse.com" <amd-sev-snp@lists.suse.com>
Subject: Re: [EXTERNAL] Re: SVSM Attestation and vTPM specification additions - v0.61
Date: Sat, 25 Feb 2023 07:33:09 +0100	[thread overview]
Message-ID: <Y/mrpV/pPxUontKF@suse.de> (raw)
In-Reply-To: <MN0PR21MB3072CC6E9027D4B75560E05FCAA89@MN0PR21MB3072.namprd21.prod.outlook.com>

On Fri, Feb 24, 2023 at 07:02:21PM +0000, Jon Lange wrote:
> If the target VMSA is running, then the attempt by the SVSM to access
> it will generate #NPF since the RMP entry for the running VMSA is
> modified to a locked state while the VMSA is running.  This means that
> if the SVSM observes that the instruction that clears EFER.SVME
> retires, then it must have succeeded, and the next time the VMSA is
> selected to run, it will fail with a non-canonical VM state.

Yes, that #NPF happening is what Tom told me too. That is a bit
unfortunate, though, since that #NPF gives control to the HV and we
don't have a way to handle the situation within the SVSM. Best case is
that the HV kills the VM when this happens, worst case is that it loops
over that #NPF as long as the VMSA is running.

In any case the SVSM will not _know_ that the VMSA was busy and can not
return the FAIL_INUSE error to the higher VMPL. We can partially work
around that by manually tracking the busy state within the SVSM. But
that doesn't protect from a malicious HV which randomly executes VMSAs.

Anyway, that's the way it is, I guess. 

Regards,

-- 
Jörg Rödel
jroedel@suse.de

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman


  reply	other threads:[~2023-02-25  6:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08 21:55 SVSM Attestation and vTPM specification additions - v0.61 Tom Lendacky
2023-02-08 23:19 ` Dionna Amalie Glaze
2023-02-08 23:44   ` Tom Lendacky
2023-02-15  9:49 ` Jörg Rödel
2023-02-21 22:07   ` Tom Lendacky
2023-02-24 14:15     ` Jörg Rödel
2023-02-24 19:02       ` [EXTERNAL] " Jon Lange
2023-02-25  6:33         ` Jörg Rödel [this message]
2023-02-27 17:03           ` Jon Lange
2023-03-01  8:56             ` Jörg Rödel
2023-03-01 14:00               ` Tom Lendacky
2023-03-01 15:00       ` Tom Lendacky
2023-02-15 14:57 ` Tom Lendacky
2023-03-06 10:33 ` Dov Murik

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=Y/mrpV/pPxUontKF@suse.de \
    --to=jroedel@suse.de \
    --cc=amd-sev-snp@lists.suse.com \
    --cc=jlange@microsoft.com \
    --cc=linux-coco@lists.linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.