From: "Lendacky, Thomas via groups.io" <thomas.lendacky=amd.com@groups.io>
To: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
devel@edk2.groups.io, Gerd Hoffmann <kraxel@redhat.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: dov.murik@gmail.com, james.bottomley@hansenpartnership.com,
tobin@ibm.com
Subject: Re: [edk2-devel] [PATCH 1/2] AmdSev: Rework Blob Verifier
Date: Thu, 30 May 2024 10:46:06 -0500 [thread overview]
Message-ID: <b7713dc8-a4ce-c9b6-1f18-d9a02dd15240@amd.com> (raw)
In-Reply-To: <a96f4a37a06eb7b44b989f9e1ce7c4728d196b3b.1715024059.git.tobin@linux.ibm.com>
On 5/6/24 15:27, Tobin Feldman-Fitzthum wrote:
> The Blob Verifier checks boot artifacts against a hash table
> injected by the hypervisor and measured by hardware.
>
> Update the Blob Verifier to enter a dead loop if the artifacts
> do not match.
There are some changes to messages from ERROR to WARN and the return is
kept as EFI_ACCESS_DENIED, so it would be best to describe in the commit
message what situations result in EFI_ACCES_DENIED vs dead loop.
>
> Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
> ---
> .../BlobVerifierSevHashes.c | 39 +++++++++++++++----
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
> index 2e58794c3c..ee8bca509a 100644
> --- a/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
> +++ b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
> @@ -77,13 +77,17 @@ FindBlobEntryGuid (
> /**
> Verify blob from an external source.
>
> + If a non-secure configuration is detected this function will enter a
> + dead loop to prevent a boot.
> +
> @param[in] BlobName The name of the blob
> @param[in] Buf The data of the blob
> @param[in] BufSize The size of the blob in bytes
>
> - @retval EFI_SUCCESS The blob was verified successfully.
> - @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
> - should be considered non-secure.
> + @retval EFI_SUCCESS The blob was verified successfully or was not
> + found in the hash table.
> + @retval EFI_ACCESS_DENIED Kernel hashes not supported, but the boot
> + can continue safely.
> **/
> EFI_STATUS
> EFIAPI
> @@ -99,8 +103,8 @@ VerifyBlob (
>
> if ((mHashesTable == NULL) || (mHashesTableSize == 0)) {
> DEBUG ((
> - DEBUG_ERROR,
> - "%a: Verifier called but no hashes table discoverd in MEMFD\n",
> + DEBUG_WARN,
> + "%a: No hashes table discovered in MEMFD\n",
Technically, this should really just change the ERROR to WARN without
changing the message text.
> __func__
> ));
> return EFI_ACCESS_DENIED;
> @@ -114,7 +118,8 @@ VerifyBlob (
> __func__,
> BlobName
> ));
> - return EFI_ACCESS_DENIED;
> +
> + CpuDeadLoop ();
> }
>
> //
> @@ -136,10 +141,22 @@ VerifyBlob (
>
> DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __func__, Guid));
>
> + if (BufSize == 0) {
> + DEBUG ((
> + DEBUG_ERROR,
> + "%a: Blob Specified in Hash Table was not Provided",
> + __func__,
> + EntrySize,
> + SHA256_DIGEST_SIZE
Looks like there's no substitution spots in the message for these last
two parameters.
Thanks,
Tom
> + ));
> +
> + CpuDeadLoop ();
> + }
> +
> EntrySize = Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;
> if (EntrySize != SHA256_DIGEST_SIZE) {
> DEBUG ((
> - DEBUG_ERROR,
> + DEBUG_WARN,
> "%a: Hash has the wrong size %d != %d\n",
> __func__,
> EntrySize,
> @@ -170,18 +187,24 @@ VerifyBlob (
> __func__,
> BlobName
> ));
> +
> + CpuDeadLoop ();
> }
>
> return Status;
> }
>
> + //
> + // If the GUID is not in the hash table, execution can still continue.
> + // This blob will not be measured, but at least one blob must be.
> + //
> DEBUG ((
> DEBUG_ERROR,
> "%a: Hash GUID %g not found in table\n",
> __func__,
> Guid
> ));
> - return EFI_ACCESS_DENIED;
> + return EFI_SUCCESS;
> }
>
> /**
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119397): https://edk2.groups.io/g/devel/message/119397
Mute This Topic: https://groups.io/mt/105977014/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2024-05-30 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 20:27 [edk2-devel] [PATCH 0/2] AmdSev: Harden SEV Kernel hashes verifier Tobin Feldman-Fitzthum
2024-05-06 20:27 ` [edk2-devel] [PATCH 1/2] AmdSev: Rework Blob Verifier Tobin Feldman-Fitzthum
2024-05-30 15:46 ` Lendacky, Thomas via groups.io [this message]
2024-05-06 20:27 ` [edk2-devel] [PATCH 2/2] AmdSev: Halt on failed blob allocation Tobin Feldman-Fitzthum
2024-05-30 15:51 ` Lendacky, Thomas via groups.io
2024-06-26 8:08 ` [edk2-devel] [PATCH 0/2] AmdSev: Harden SEV Kernel hashes verifier Aithal, Srikanth via groups.io
2024-06-26 13:58 ` Tobin Feldman-Fitzthum
2024-06-26 14:33 ` Aithal, Srikanth via groups.io
2024-06-26 17:14 ` Tobin Feldman-Fitzthum
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-list 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=b7713dc8-a4ce-c9b6-1f18-d9a02dd15240@amd.com \
--to=devel@edk2.groups.io \
/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