All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Nikunj A Dadhania <nikunj@amd.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	kvm@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de,
	dave.hansen@linux.intel.com, seanjc@google.com,
	pbonzini@redhat.com, thomas.lendacky@amd.com,
	michael.roth@amd.com, stable@kernel.org
Subject: Re: [PATCH v2] x86/sev: Add SEV-SNP guest feature negotiation support
Date: Mon, 5 Dec 2022 15:30:49 +0100	[thread overview]
Message-ID: <Y44Amf9MJIIi4Ric@zn.tnic> (raw)
In-Reply-To: <20221201100423.7117-1-nikunj@amd.com>

On Thu, Dec 01, 2022 at 03:34:23PM +0530, Nikunj A Dadhania wrote:
> The hypervisor can enable various new features (SEV_FEATURES[1:63])
> and start the SNP guest. Some of these features need guest side
> implementation. If any of these features are enabled without guest
> side implementation, the behavior of the SNP guest will be undefined.
> The SNP guest boot may fail in a non-obvious way making it difficult
> to debug.
> 
> Instead of allowing the guest to continue and have it fail randomly
> later, detect this early and fail gracefully.
> 
> SEV_STATUS MSR indicates features which hypervisor has enabled. While
> booting, SNP guests should ascertain that all the enabled features
> have guest side implementation. In case any feature is not implemented
> in the guest, the guest terminates booting with SNP feature
> unsupported exit code.
> 
> The below table lists the expected guest behavior with various
> possible scenarios of guest/hypervisor SNP feature support.
> 
> +---------------+---------------+---------------+---------------+
> |Feature Enabled|  Guest needs  |   Guest has   |  Guest boot   |
> |     by HV     |implementation |implementation |   behavior    |
> +---------------+---------------+---------------+---------------+
> |      No       |      No       |      No       |     Boot      |
> |               |               |               |               |
> +---------------+---------------+---------------+---------------+
> |      No       |      Yes      |      No       |     Boot      |
> |               |               |               |               |
> +---------------+---------------+---------------+---------------+
> |      No       |      Yes      |      Yes      |     Boot      |
> |               |               |               |               |
> +---------------+---------------+---------------+---------------+
> |      Yes      |      No       |      No       |   Boot with   |
> |               |               |               |feature enabled|
> +---------------+---------------+---------------+---------------+
> |      Yes      |      Yes      |      No       | Graceful Boot |
> |               |               |               |    Failure    |
> +---------------+---------------+---------------+---------------+
> |      Yes      |      Yes      |      Yes      |   Boot with   |
> |               |               |               |feature enabled|
> +---------------+---------------+---------------+---------------+

I like this table and I wouldn't want for it to go under in some commit
message which is not that easy to retrieve so I'm thinking you should
add it along with some blurb to

  Documentation/x86/amd-memory-encryption.rst

instead where it belongs.

> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index c93930d5ccbd..571eb2576475 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -270,6 +270,50 @@ static void enforce_vmpl0(void)
>  		sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_NOT_VMPL0);
>  }
>  
> +/*
> + * SNP_FEATURES_NEED_GUEST_IMPLEMENTATION is the mask of SNP features that
> + * will need guest side implementation for proper functioning of the guest.
> + * If any of these features are enabled without guest side implementation,

"... are enabled in the hypervisor ... "

> + * the behavior of the guest will be undefined. The guest may fail in
> + * non-obvious way making it difficult to debug.
> + *
> + * SNP reserved feature bits may or may not need guest side implementation.

Yah, get rid of that PPR formulation. If you see the verb "may" always
run away. :-)

> + * As the behavior of reserved feature bits are unknown, to be on the safer
> + * side add them to the NEED_GUEST_IMPLEMENTATION mask.

Yah, that makes sense - you want to protect those for future use. Ack.

> + */
> +#define SNP_FEATURES_NEED_GUEST_IMPLEMENTATION (MSR_AMD64_SNP_VTOM |			\

SNP_FEATURES_REQUIRED

Simpler and shorter.

> +						MSR_AMD64_SNP_REFLECT_VC |		\
> +						MSR_AMD64_SNP_RESTRICTED_INJ |		\
> +						MSR_AMD64_SNP_ALT_INJ |			\
> +						MSR_AMD64_SNP_DEBUG_SWAP |		\
> +						MSR_AMD64_SNP_VMPL_SSS |		\
> +						MSR_AMD64_SNP_SECURE_TSC |		\
> +						MSR_AMD64_SNP_VMGEXIT_PARAM |		\
> +						MSR_AMD64_SNP_VMSA_REG_PROTECTION |	\
> +						MSR_AMD64_SNP_RESERVED_BIT13 |		\
> +						MSR_AMD64_SNP_RESERVED_BIT15 |		\
> +						MSR_AMD64_SNP_RESERVED_MASK)
> +
> +/*
> + * SNP_FEATURES_HAS_GUEST_IMPLEMENTATION is the mask of SNP features that are
> + * implemented by the guest kernel. As and when a new feature is implemented
> + * in the guest kernel, a corresponding bit should be added to the mask.

And there's no way we won't notice that we've forgotten to do so because
it'll terminate with the proper error code.

> + */
> +#define SNP_FEATURES_HAS_GUEST_IMPLEMENTATION (0)

SNP_FEATURES_PRESENT

And so I've done a couple of changes ontop, here's a diff as it explains
a lot better what I mean.

Have a look and let me know if something's wrong.

Thx.

---
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 10272835dfe9..f023d37e2c41 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -271,48 +271,35 @@ static void enforce_vmpl0(void)
 }
 
 /*
- * SNP_FEATURES_NEED_GUEST_IMPLEMENTATION is the mask of SNP features that
- * will need guest side implementation for proper functioning of the guest.
- * If any of these features are enabled without guest side implementation,
- * the behavior of the guest will be undefined. The guest may fail in
- * non-obvious way making it difficult to debug.
- *
- * SNP reserved feature bits may or may not need guest side implementation.
- * As the behavior of reserved feature bits are unknown, to be on the safer
- * side add them to the NEED_GUEST_IMPLEMENTATION mask.
- */
-#define SNP_FEATURES_NEED_GUEST_IMPLEMENTATION (MSR_AMD64_SNP_VTOM |			\
-						MSR_AMD64_SNP_REFLECT_VC |		\
-						MSR_AMD64_SNP_RESTRICTED_INJ |		\
-						MSR_AMD64_SNP_ALT_INJ |			\
-						MSR_AMD64_SNP_DEBUG_SWAP |		\
-						MSR_AMD64_SNP_VMPL_SSS |		\
-						MSR_AMD64_SNP_SECURE_TSC |		\
-						MSR_AMD64_SNP_VMGEXIT_PARAM |		\
-						MSR_AMD64_SNP_VMSA_REG_PROTECTION |	\
-						MSR_AMD64_SNP_RESERVED_BIT13 |		\
-						MSR_AMD64_SNP_RESERVED_BIT15 |		\
-						MSR_AMD64_SNP_RESERVED_MASK)
 
-/*
- * SNP_FEATURES_HAS_GUEST_IMPLEMENTATION is the mask of SNP features that are
- * implemented by the guest kernel. As and when a new feature is implemented
- * in the guest kernel, a corresponding bit should be added to the mask.
+ * SNP_FEATURES_REQUIRED is the mask of SNP features that will need
+ * guest side implementation for proper functioning of the guest. If any
+ * of these features are enabled in the hypervisor but are lacking guest
+ * side implementation, the behavior of the guest will be undefined. The
+ * guest could fail in non-obvious way making it difficult to debug.
+ *
+ * As the behavior of reserved feature bits is unknown to be on the
+ * safe side add them to the required features mask.
  */
-#define SNP_FEATURES_HAS_GUEST_IMPLEMENTATION (0)
+#define SNP_FEATURES_REQUIRED		(MSR_AMD64_SNP_VTOM |			\
+					MSR_AMD64_SNP_REFLECT_VC |		\
+					MSR_AMD64_SNP_RESTRICTED_INJ |		\
+					MSR_AMD64_SNP_ALT_INJ |			\
+					MSR_AMD64_SNP_DEBUG_SWAP |		\
+					MSR_AMD64_SNP_VMPL_SSS |		\
+					MSR_AMD64_SNP_SECURE_TSC |		\
+					MSR_AMD64_SNP_VMGEXIT_PARAM |		\
+					MSR_AMD64_SNP_VMSA_REG_PROTECTION |	\
+					MSR_AMD64_SNP_RESERVED_BIT13 |		\
+					MSR_AMD64_SNP_RESERVED_BIT15 |		\
+					MSR_AMD64_SNP_RESERVED_MASK)
 
 /*
- * The hypervisor can enable various features flags (in SEV_FEATURES[1:63]) and
- * start the SNP guest. Certain SNP features need guest side implementation.
- * Check if the SNP guest has implementation for those features.
+ * SNP_FEATURES_PRESENT is the mask of SNP features that are implemented
+ * by the guest kernel. As and when a new feature is implemented in the
+ * guest kernel, a corresponding bit should be added to the mask.
  */
-static bool snp_guest_has_features_implemented(void)
-{
-	u64 guest_features_not_implemented = SNP_FEATURES_NEED_GUEST_IMPLEMENTATION &
-		~SNP_FEATURES_HAS_GUEST_IMPLEMENTATION;
-
-	return !(sev_status & guest_features_not_implemented);
-}
+#define SNP_FEATURES_PRESENT (0)
 
 void sev_enable(struct boot_params *bp)
 {
@@ -383,7 +370,7 @@ void sev_enable(struct boot_params *bp)
 		 * Terminate the boot if hypervisor has enabled any feature
 		 * missing guest side implementation.
 		 */
-		if (!snp_guest_has_features_implemented())
+		if (sev_status & SNP_FEATURES_REQUIRED & ~SNP_FEATURES_PRESENT)
 			sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_FEAT_NOT_IMPLEMENTED);
 
 		enforce_vmpl0();

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2022-12-05 14:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 10:04 [PATCH v2] x86/sev: Add SEV-SNP guest feature negotiation support Nikunj A Dadhania
2022-12-05 14:30 ` Borislav Petkov [this message]
2022-12-05 15:02   ` Nikunj A. Dadhania
2022-12-05 15:07     ` Borislav Petkov
2022-12-05 15:23   ` Tom Lendacky
2022-12-05 15:46     ` Borislav Petkov

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=Y44Amf9MJIIi4Ric@zn.tnic \
    --to=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=stable@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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.