Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver

["Gerd Hoffmann" <kraxel@redhat.com>]

On Thu, Mar 14, 2024 at 12:05:28PM +0000, Yao, Jiewen wrote:
> I agree that not all bits make sense to virtual machine.
> However, I do see some bits should be there if we really want to add HSTI to report security propery.

Setting the bits which are obviously correct makes sense indeed.

> Please take a look at the HSTI spec - https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification
> For example:
> Do you use RSA 2048 and SHA256 only (or higher but not lower than this)

Hmm.  That single line (and the spec doesn't have more) is not very
helpful.  Consider this corner case:

The virtual TPM supported by qemu has banks for sha1, sha256, sha384 and
sha512.  The default configuration created by libvirt enables only the
sha256 bank.  But it's possible to go into the firmware setup and turn
on the sha1 bank too.

How should the HSTI driver handle that?

> Compatibility Support Modules (CSM)

That one is easy, CSM support is gone, we can set it.

> Firmware Code must be present in protected storage

Typically this is the case (ROM or read-only flash), although qemu
does not enforce that the code flash is actually read-only, it can
be configured in writable mode.

Hmm.

> Secure firmware update process

IMHO doesn't apply to virtual machines.  Firmware updates are usually
handled by updating the images on the host machine, that is very
different from a physical machine.  All the questions about key handling
do not make any sense.

> Do you have backdoors to override SecureBoot

No (you can only turn it off altogether).  I think we can set this (in
secure boot enabled builds).

Use "FeaturePcdGet (PcdSecureBootSupported)" to figure whenever a given
build supports secure boot or not.

> Protection from internal and external DMA

I don't think qemu supports DMA access to NV (aka flash) storage.
Is that good enough to set that bit?

> Another question: I notice you report platform as “Intel(R) 9-Series v1”.
> Is that right configuration for current OVMF?

Probably refers to q35 (aka INTEL_Q35_MCH_DEVICE_ID).

> I think there is some configuration detection, such as https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/Platform.c.

Looking at PlatformInfoHob->HostBridgeDevId and setting the name
accordingly makes sense indeed.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116813): https://edk2.groups.io/g/devel/message/116813
Mute This Topic: https://groups.io/mt/104923813/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-