Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
Please let me summarize my feedback: 0) In general, please don't just say something is "secure" or "not secure". Without a clear threat mode, it just brings confusing to other security people. I recommend we describe clearly on the TCB assumption, adversary, vulnerability, etc. 1) I recommend we add a new section in README and put the information there. Once we finish the document description, we have a clear picture on what configuration we think is legal for a production (CC or non-CC use case). Then we can add ASSERT for the illegal configuration. 2) Because the TCB in CC and Non-CC is different, I recommend we separate the description based upon different threat models. NOTE: In non-CC use case, virtual SMM is considered as TCB. In CC use case, virtual SMM is not in TCB. If you want to discuss SMM, please describe clearly if SMM in TCB or not. 3) I don't think we need introduce a new term "stateless". If "stateless" == no persistent variable store, I recommend we just call it "no-persistent". In general, I could think of below the types: A) NV storage (protected and measured by TCB): Update from SetVariable is kept in next boot and protected by TCB. The verifier can know its state with attestation. B) NV storage (protected but not measured by TCB): Update from SetVariable is kept in next boot and protected by TCB. C) NV storage (not protected but measured by TCB): Update from SetVariable is kept in next boot (ideally) and not protected by TCB. A non-TCB may update the Var region at any time. The verifier can know its state with attestation. D) NV storage (not protected and not measured by TCB): Update from SetVariable is kept in next boot (ideally) and not protected by TCB. A non-TCB may update the Var region at any time. And it is not detectable. E) no NV storage: Update from SetVariable is not kept in next boot. Do you mean stateless == no-persistent == E)? Or something else? Thank you Yao Jiewen > -Original Message- > From: kra...@redhat.com > Sent: Tuesday, December 20, 2022 3:19 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Justen, Jordan L ; Ard > Biesheuvel ; Oliver Steffen > ; Pawel Polawski > Subject: Re: [edk2-devel] [PATCH 1/1] > OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning > > Hi, > > > > Well, the OS can write directly to flash, bypassing the firmware. It > > > can update secure boot efi variables without the firmware enforcing the > > > usual restrictions (KEK signature being required for db/dbx updates > > > etc). > > > > [Jiewen] I would say: It is the typical use case. But not the only use case. > > Typically, the BIOS shall configure the flash to prevent OS directly to > > flash, > with SMM in this case. I do not disagree. > > That feature fully really on the hardware (on a real platform) or VMM (on a > virtual platform). > > > > However, in confidential computing use case, the flash is controlled by the > untrusted entity - VMM. > > It is *impossible* to lock down the flash, even with SMM enabled. That is > because the VMM is also emulating SMM. > > To rely on an untrusted entity (VMM) to provide security protection (e.g. > SMM) is meaningless. > > In the confidential computing use case there is no flash in the first > place. At least for the cases where the processor not the VMM manages > guest memory (i.e SEV-SNP and TDX) the qemu patches I've seen so far > handle it that way. > > That configuration goes into the (3a) bucket. No flash (and no other > place to store any state which survives reboot -> stateless). Guest > starts with a fixed varstore coming from the firmware rom. > > > The best way we can do is to enable measured boot together with secure > > boot. > > measured boot can be used to attest the VM actually runs the > configuration it is supposed to run. That is independent from secure > boot, even though it is possible to combine the two and in that case > also measure secure boot configuration. > > Works in both confidential and non-confidential VMs. > > > In summary, Secure boot in CC cannot resist the policy override, > > but Measured boot in CC will detect such override, and mitigate such threat. > > That is fine, because it is meaningless to enable CC without measured boot. > > If you don't want trust the VMM, then yes, measured boot is required to > make sure the VMM actually started the VM the way it is supposed to be > started. > > For attacks against the guest OS there isn't that much of a difference > between CC and non-CC guests. I think in both cases the (hacked) guest > OS can't change the secure boot configuration. Even in case the guest > OS manages to modify the varstore the fi
Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
Hi, > > Well, the OS can write directly to flash, bypassing the firmware. It > > can update secure boot efi variables without the firmware enforcing the > > usual restrictions (KEK signature being required for db/dbx updates > > etc). > > [Jiewen] I would say: It is the typical use case. But not the only use case. > Typically, the BIOS shall configure the flash to prevent OS directly to > flash, with SMM in this case. I do not disagree. > That feature fully really on the hardware (on a real platform) or VMM (on a > virtual platform). > > However, in confidential computing use case, the flash is controlled by the > untrusted entity - VMM. > It is *impossible* to lock down the flash, even with SMM enabled. That is > because the VMM is also emulating SMM. > To rely on an untrusted entity (VMM) to provide security protection (e.g. > SMM) is meaningless. In the confidential computing use case there is no flash in the first place. At least for the cases where the processor not the VMM manages guest memory (i.e SEV-SNP and TDX) the qemu patches I've seen so far handle it that way. That configuration goes into the (3a) bucket. No flash (and no other place to store any state which survives reboot -> stateless). Guest starts with a fixed varstore coming from the firmware rom. > The best way we can do is to enable measured boot together with secure > boot. measured boot can be used to attest the VM actually runs the configuration it is supposed to run. That is independent from secure boot, even though it is possible to combine the two and in that case also measure secure boot configuration. Works in both confidential and non-confidential VMs. > In summary, Secure boot in CC cannot resist the policy override, > but Measured boot in CC will detect such override, and mitigate such threat. > That is fine, because it is meaningless to enable CC without measured boot. If you don't want trust the VMM, then yes, measured boot is required to make sure the VMM actually started the VM the way it is supposed to be started. For attacks against the guest OS there isn't that much of a difference between CC and non-CC guests. I think in both cases the (hacked) guest OS can't change the secure boot configuration. Even in case the guest OS manages to modify the varstore the firmware will never use the modification. For non-confidential guests the firmware will initialize the varstore with the pristine copy from firmware rom on reset. For CC guests there is no reset in the first place (reset requires the VMM changing guest state), you can only kill and restart the VM, which will likewise start with pristine varstore state. > > I don't see how "secure boot without SMM" is easier to understand than > > "stateless". > > [Jiewen] "stateless" is a new term introduced in this patch. Not in UEFI > spec, nor in EDKII. > If you want to use it, please define it clearly. At least, I don't understand. "stateless" == no persistent variable store, i.e. no flash. > > It also is x64-specific. > > [Jiewen] I don't understand why it is x64-specific. SMM is x86-specific, that's why I don't like the term "secure boot without SMM". > > > 4) What is the purpose of "Log a warning" ? > > > Is that to tell people, DON'T DO IT? > > > > Yes. > > [Jiewen] Disagree. It can work together with measured boot in CC use case. > If you really really want to add something, you should also check if CC is > enabled. See above. CC runs without flash anyway so no warning in that case. > > In 2022-08 and older the world is relatively simple. We have > > three possible build configurations > > > > (1) SECURE_BOOT_ENABLE=FALSE SMM_REQUIRE=FALSE > > Build without secure boot support. > > > > (2) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=TRUE > > Build with secure boot support, secure. > > > > (3) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=FALSE > > Build with secure boot support, not secure. > > > > Linux Distributions typically provide builds for (1) and (2), > > so (3) existing isn't much of a problem in practice because > > people typically don't compile edk2 by themself. > > [Jiewen] Above description is based upon assumption that SMM is trusted. Yes. > It is TRUE in non-CC use case. However, the assumption is wrong in CC > use case, because VMM is untrusted and SMM might colluder. The VMM > may fake the flash lock in SMM, and allow OS to bypass the flash > protection. Following your logic, I would say: even with SMM, it is > still not secure. Not sure what you are trying to tell me. In CC mode SMM is not supported in the first place, so your argument doesn't make sense to me. > > In 2022-11 the (3) case is splitted into two: > > > > (3a) build being used with ROM (or r/o flash): > >-> this is the new "stateless secure boot" mode. > > (3b) build being used with writable flash: > >-> insecure configuration. > > [Jiewen] If you want to use term "stateless", please define it. "stateless"
Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
> -Original Message- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Monday, December 19, 2022 4:53 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Justen, Jordan L ; Ard > Biesheuvel ; Oliver Steffen > ; Pawel Polawski > Subject: Re: [edk2-devel] [PATCH 1/1] > OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning > > On Sat, Dec 17, 2022 at 03:10:25AM +, Yao, Jiewen wrote: > > Hi Gerd > > I would like to clarify a couple of things: > > > > 1) "Using these builds with writable flash is not secure." > > > > Whenever we say "secure" or "not secure", we need align the threat model > at first. > > What component is trusted? Which is not trusted? Who is adversary? With > which capability? Under which attack scenario? > > Well, the OS can write directly to flash, bypassing the firmware. It > can update secure boot efi variables without the firmware enforcing the > usual restrictions (KEK signature being required for db/dbx updates > etc). [Jiewen] I would say: It is the typical use case. But not the only use case. Typically, the BIOS shall configure the flash to prevent OS directly to flash, with SMM in this case. I do not disagree. That feature fully really on the hardware (on a real platform) or VMM (on a virtual platform). However, in confidential computing use case, the flash is controlled by the untrusted entity - VMM. It is *impossible* to lock down the flash, even with SMM enabled. That is because the VMM is also emulating SMM. To rely on an untrusted entity (VMM) to provide security protection (e.g. SMM) is meaningless. The best way we can do is to enable measured boot together with secure boot. As such, no matter how VMM or untrusted OS modifies the SecureBoot variable, it will be recorded by measured boot mechanism and detected in attestation later. In summary, Secure boot in CC cannot resist the policy override, but Measured boot in CC will detect such override, and mitigate such threat. That is fine, because it is meaningless to enable CC without measured boot. > > > If we are going to say something like that, we need a full description. Just > saying: "not secure" is not enough. > > We simply don't get the protection secure boot is supposed to provide. > > > 3) What is definition of "stateless secure boot configuration" ? > > What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or > something else? > > "stateless" means we don't have persistent efi variables. > > > Then why not call it as simple as "secure boot without SMM" ? > > I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless". > > Secure boot in OVMF in 2022-08 + older requires flash memory as efi > variables storage and SMM mode support to enforce all efi variable > updates being handled by the firmware. > > Starting with 2022-11 it is also possible to use secure boot without SNN > mode and with the emulated variable store in RAM. Min added that for > IntelTdx. The firmware can't enforce variable update rules in that > case, but that is compensated by initializing the emulated variable > store content with a pristine copy from ROM on each boot. So the OS can > tamper with the efi variables, but it can't attack the system that way > because any changes done are wiped on reset, before the firmware looks > at those variables again when checking efi binary signatures. This also > means any regular efi variable updates (like setting Boot* variables on > install) are wiped on reset too. This is where the term "stateless" > comes from. > > I don't see how "secure boot without SMM" is easier to understand than > "stateless". [Jiewen] "stateless" is a new term introduced in this patch. Not in UEFI spec, nor in EDKII. If you want to use it, please define it clearly. At least, I don't understand. > It also is x64-specific. [Jiewen] I don't understand why it is x64-specific. > But the idea to give up variable > persistence to get secure boot support without processor support for a > separate privilege level can work on other platforms too. ArmVirt for > example could get secure boot support that way without depending on > TrustZone. > > > 4) What is the purpose of "Log a warning" ? > > Is that to tell people, DON'T DO IT? > > Yes. [Jiewen] Disagree. It can work together with measured boot in CC use case. If you really really want to add something, you should also check if CC is enabled. > > Maybe it's better to refuse to boot in that case, [Jiewen] You may refuse in non-CC case. But it is legal in CC case. > a warni
Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
On Sat, Dec 17, 2022 at 03:10:25AM +, Yao, Jiewen wrote: > Hi Gerd > I would like to clarify a couple of things: > > 1) "Using these builds with writable flash is not secure." > > Whenever we say "secure" or "not secure", we need align the threat model at > first. > What component is trusted? Which is not trusted? Who is adversary? With which > capability? Under which attack scenario? Well, the OS can write directly to flash, bypassing the firmware. It can update secure boot efi variables without the firmware enforcing the usual restrictions (KEK signature being required for db/dbx updates etc). > If we are going to say something like that, we need a full description. Just > saying: "not secure" is not enough. We simply don't get the protection secure boot is supposed to provide. > 3) What is definition of "stateless secure boot configuration" ? > What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or something > else? "stateless" means we don't have persistent efi variables. > Then why not call it as simple as "secure boot without SMM" ? > I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless". Secure boot in OVMF in 2022-08 + older requires flash memory as efi variables storage and SMM mode support to enforce all efi variable updates being handled by the firmware. Starting with 2022-11 it is also possible to use secure boot without SNN mode and with the emulated variable store in RAM. Min added that for IntelTdx. The firmware can't enforce variable update rules in that case, but that is compensated by initializing the emulated variable store content with a pristine copy from ROM on each boot. So the OS can tamper with the efi variables, but it can't attack the system that way because any changes done are wiped on reset, before the firmware looks at those variables again when checking efi binary signatures. This also means any regular efi variable updates (like setting Boot* variables on install) are wiped on reset too. This is where the term "stateless" comes from. I don't see how "secure boot without SMM" is easier to understand than "stateless". It also is x64-specific. But the idea to give up variable persistence to get secure boot support without processor support for a separate privilege level can work on other platforms too. ArmVirt for example could get secure boot support that way without depending on TrustZone. > 4) What is the purpose of "Log a warning" ? > Is that to tell people, DON'T DO IT? Yes. Maybe it's better to refuse to boot in that case, a warning in a logfile is easily missed. In 2022-08 and older the world is relatively simple. We have three possible build configurations (1) SECURE_BOOT_ENABLE=FALSE SMM_REQUIRE=FALSE Build without secure boot support. (2) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=TRUE Build with secure boot support, secure. (3) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=FALSE Build with secure boot support, not secure. Linux Distributions typically provide builds for (1) and (2), so (3) existing isn't much of a problem in practice because people typically don't compile edk2 by themself. In 2022-11 the (3) case is splitted into two: (3a) build being used with ROM (or r/o flash): -> this is the new "stateless secure boot" mode. (3b) build being used with writable flash: -> insecure configuration. Now the same build can be secure or not depending on runtime configuration. So this patch tries to catch (3b) with a runtime check. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97554): https://edk2.groups.io/g/devel/message/97554 Mute This Topic: https://groups.io/mt/95707152/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
Sorry, fix typo:
2. With reason above, I feel that adding comment in the code might not be the
best idea, because it is so simple that it will easily introduce
misunderstanding and confusing.
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Yao,
> Jiewen
> Sent: Saturday, December 17, 2022 11:10 AM
> To: Gerd Hoffmann ; devel@edk2.groups.io
> Cc: Justen, Jordan L ; Ard Biesheuvel
> ; Oliver Steffen ; Pawel
> Polawski
> Subject: Re: [edk2-devel] [PATCH 1/1]
> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
>
> Hi Gerd
> I would like to clarify a couple of things:
>
> 1) "Using these builds with writable flash is not secure."
>
> Whenever we say "secure" or "not secure", we need align the threat model
> at first.
> What component is trusted? Which is not trusted? Who is adversary? With
> which capability? Under which attack scenario?
>
> Sometimes, we also say: "UEFI secure boot is not secure", because it cannot
> resist the offline hardware attack the flash chip.
> We only say "UEFI secure boot can resist the system software attack."
>
> Also many time, we need debate if DOS attack is in scope or not.
>
> If we are going to say something like that, we need a full description. Just
> saying: "not secure" is not enough.
>
> 2) With reason above, I feel that adding comment in the code might not be
> the best idea, because it is too simple to introduce misunderstanding and
> confusing.
> Can we add better description in readme? Such as
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
>
> 3) What is definition of "stateless secure boot configuration" ?
> What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or
> something else?
> Then why not call it as simple as "secure boot without SMM" ?
> I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless".
>
> I hope we can clarify the terminology if we choose 2).
>
> 4) What is the purpose of "Log a warning" ?
> Is that to tell people, DON'T DO IT?
> Or is that to tell people, you may play with it by yourself, but don't use it
> a
> production?
> Or something else?
>
> I think we need give a clear answer after we clarify the threat model.
> Otherwise, a WARNING just adds confusing, IMHO.
>
> Thank you
> Yao Jiewen
>
>
> > -Original Message-
> > From: Gerd Hoffmann
> > Sent: Friday, December 16, 2022 6:12 PM
> > To: devel@edk2.groups.io
> > Cc: Justen, Jordan L ; Gerd Hoffmann
> > ; Ard Biesheuvel ;
> Oliver
> > Steffen ; Pawel Polawski ;
> > Yao, Jiewen
> > Subject: [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add
> > security warning
> >
> > OVMF builds in stateless secure boot configuration
> > (SECURE_BOOT_ENABLE=TRUE + SMM_REQUIRE=FALSE) are expected to
> use
> > the
> > emulated variable store (EmuVariableFvbRuntimeDxe) with the store being
> > re-initialized on each reset (see PlatformInitEmuVariableNvStore())
> >
> > Using these builds with writable flash is not secure. Log a warning
> > message saying so in case we find such a configuration.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c | 5
> +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git
> a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> > b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> > index 61e1f2e196e5..ab7154685424 100644
> > --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> > +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> > @@ -57,6 +57,11 @@ InstallProtocolInterfaces (
> > NULL
> > );
> > ASSERT_EFI_ERROR (Status);
> > + #ifdef SECURE_BOOT_FEATURE_ENABLED
> > +DEBUG ((DEBUG_WARN, "This build is configured for stateless secure
> > boot.\n"));
> > +DEBUG ((DEBUG_WARN, "Using this build with writable flash is NOT
> > secure.\n"));
> > +// should we ASSERT(0) here?
> > + #endif
> >} else if (IsDevicePathEnd (FvbDevice->DevicePath)) {
> > //
> > // Device already exists, so reinstall the FVB protocol
> > --
> > 2.38.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97522): https://edk2.groups.io/g/devel/message/97522
Mute This Topic: https://groups.io/mt/95707152/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
Hi Gerd
I would like to clarify a couple of things:
1) "Using these builds with writable flash is not secure."
Whenever we say "secure" or "not secure", we need align the threat model at
first.
What component is trusted? Which is not trusted? Who is adversary? With which
capability? Under which attack scenario?
Sometimes, we also say: "UEFI secure boot is not secure", because it cannot
resist the offline hardware attack the flash chip.
We only say "UEFI secure boot can resist the system software attack."
Also many time, we need debate if DOS attack is in scope or not.
If we are going to say something like that, we need a full description. Just
saying: "not secure" is not enough.
2) With reason above, I feel that adding comment in the code might not be the
best idea, because it is too simple to introduce misunderstanding and confusing.
Can we add better description in readme? Such as
https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
3) What is definition of "stateless secure boot configuration" ?
What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or something
else?
Then why not call it as simple as "secure boot without SMM" ?
I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless".
I hope we can clarify the terminology if we choose 2).
4) What is the purpose of "Log a warning" ?
Is that to tell people, DON'T DO IT?
Or is that to tell people, you may play with it by yourself, but don't use it a
production?
Or something else?
I think we need give a clear answer after we clarify the threat model.
Otherwise, a WARNING just adds confusing, IMHO.
Thank you
Yao Jiewen
> -Original Message-
> From: Gerd Hoffmann
> Sent: Friday, December 16, 2022 6:12 PM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Gerd Hoffmann
> ; Ard Biesheuvel ; Oliver
> Steffen ; Pawel Polawski ;
> Yao, Jiewen
> Subject: [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add
> security warning
>
> OVMF builds in stateless secure boot configuration
> (SECURE_BOOT_ENABLE=TRUE + SMM_REQUIRE=FALSE) are expected to use
> the
> emulated variable store (EmuVariableFvbRuntimeDxe) with the store being
> re-initialized on each reset (see PlatformInitEmuVariableNvStore())
>
> Using these builds with writable flash is not secure. Log a warning
> message saying so in case we find such a configuration.
>
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> index 61e1f2e196e5..ab7154685424 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
> @@ -57,6 +57,11 @@ InstallProtocolInterfaces (
> NULL
> );
> ASSERT_EFI_ERROR (Status);
> + #ifdef SECURE_BOOT_FEATURE_ENABLED
> +DEBUG ((DEBUG_WARN, "This build is configured for stateless secure
> boot.\n"));
> +DEBUG ((DEBUG_WARN, "Using this build with writable flash is NOT
> secure.\n"));
> +// should we ASSERT(0) here?
> + #endif
>} else if (IsDevicePathEnd (FvbDevice->DevicePath)) {
> //
> // Device already exists, so reinstall the FVB protocol
> --
> 2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97520): https://edk2.groups.io/g/devel/message/97520
Mute This Topic: https://groups.io/mt/95707152/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
OVMF builds in stateless secure boot configuration
(SECURE_BOOT_ENABLE=TRUE + SMM_REQUIRE=FALSE) are expected to use the
emulated variable store (EmuVariableFvbRuntimeDxe) with the store being
re-initialized on each reset (see PlatformInitEmuVariableNvStore())
Using these builds with writable flash is not secure. Log a warning
message saying so in case we find such a configuration.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
index 61e1f2e196e5..ab7154685424 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
@@ -57,6 +57,11 @@ InstallProtocolInterfaces (
NULL
);
ASSERT_EFI_ERROR (Status);
+ #ifdef SECURE_BOOT_FEATURE_ENABLED
+DEBUG ((DEBUG_WARN, "This build is configured for stateless secure
boot.\n"));
+DEBUG ((DEBUG_WARN, "Using this build with writable flash is NOT
secure.\n"));
+// should we ASSERT(0) here?
+ #endif
} else if (IsDevicePathEnd (FvbDevice->DevicePath)) {
//
// Device already exists, so reinstall the FVB protocol
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97502): https://edk2.groups.io/g/devel/message/97502
Mute This Topic: https://groups.io/mt/95707152/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
