Re: Lock BootOrder variable

Laszlo Ersek

On 12/18/19 11:03, Wang, Sunny (HPS SW) wrote:
Hi Sean,

Thanks for checking this further and bringing this to the Microsoft OS team.

Yeah, your guess is part of the solution that I'm working on. I'm making a spec'd way to fix this and will bring it to USWG and EDK2 design meeting to further discuss with you guys.

Moreover, I tried RHEL and SLES as well, and ran into the same problem (installation failure). Therefore, it will be good if some people from Linux OS vendors in this email list can also help drive this for Linux OS. Of course, I will still bring this to USWG for checking if we need to add a description into UEFI specification for asking/reminding OS to gracefully deal with the locked variable (and error
Locking the boot order by way of causing SetVariable to fail for the OS
seems wrong to me.

BDS is platform policy. A platform BDS implementation can simply
re-generate all Boot#### variables, and the BootOrder variable, from
scratch, every time the platform boots. Why is that not sufficient? (For
example, platform BDS could base that boot order re-generation on a set
of boot-time only variables.)

Furthermore, we already have RuntimeServicesSupported, for exposing
(among other things) that SetVariable doesn't work, "en bloc". Punching
further holes into previously promised interfaces, piece-meal, is
becoming quite baroque.

I don't understand how "security" is improved by locking down boot
order. We already have Secure Boot for executing trusted binaries only,
and we already have TCG2 / TPM2 for tying secrets to any and all aspects
of the boot path (such as executables launched, the order they are
launched in, their config files, and so on).

Anyway, I've CC'd Javier and Peter from the rhboot team.


-----Original Message-----
From: [] On Behalf Of Sean via Groups.Io
Sent: Wednesday, December 18, 2019 4:55 AM
To: Wang, Sunny (HPS SW) <>;;;; Samer El-Haj-Mahmoud <>
Cc: Spottswood, Jason <>; Haskell, Darrell <>; Wiginton, Scott <>
Subject: Re: [edk2-discuss] Lock BootOrder variable


There isn't UEFI code that is going to resolve the OS failure. I guess you could let the OS write the values and just not use those values but that is probably a bad pattern and would lead to new issues. We have talked with the Microsoft OS team about fixing this but it hasn't been a high priority. Our general guidance is don't lock the boot order until after your have deployed your OS image but there are some servicing issues that can occur.

I'll talk with the boot manager team and see if we can start to fix this in Windows. I'll update this thread if I get an answer.
Does anyone know what the different Linux loader/install process does?


-----Original Message-----
From: Wang, Sunny (HPS SW) <>
Sent: Friday, December 13, 2019 12:55 AM
To:;; Sean Brogan <>;; Samer El-Haj-Mahmoud <>
Cc: Spottswood, Jason <>; Haskell, Darrell <>; Wiginton, Scott <>; Wang, Sunny (HPS SW) <>
Subject: [EXTERNAL] RE: [edk2-discuss] Lock BootOrder variable

Thanks, guys.

Hi Samer,
Thanks for checking this and giving great information. I just knew that NIST 800-193 has some guidelines for locking down the UEFI boot order. The requirements and guidelines you added further proved the need of locking boot order.

Hi Sean,
Actually, I did check the Project Mu VariablePolicy protocol when you guys proposed this in the design meeting. This is definitely a good enhancement because I also ran into the problems mentioned in slides.
However, It looks like we would still run into the OS installation failure with the current VariablePolicy protocol implementation. I didn't deeply look into the VariablePolicy protocol or give it a try, so I may overlook the solution in your implementation. Could you help point out where the code for solving OS installation failure is? The problem here is that OS doesn't gracefully deal with the locked UEFI variable, so we may not be able to return EFI_WRITE_PROTECTED to OS for the writes to BootOrder.

Hi All,
I think we all agree with the following points:
1. There is a need to lock BootOrder like the information brought by Samer and NIST 800-193 guidelines.
2. OS needs to gracefully deal with the locked BootOrder without causing failure during the installation and operations.
3. We will at least need to update the UEFI specification for asking OS to gracefully deal with the locked variable. If no one is currently working on this, I will bring it to USWG and work on it.

Sunny Wang

-----Original Message-----
From: []
Sent: Friday, December 13, 2019 10:26 AM
To:;;; Wang, Sunny (HPS SW) <>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Sean --

Since you already have published code and it is already publicly available, then I suggest that you bring it to USWG now, rather than later.



-----Original Message-----
From: <> On Behalf Of Sean via Groups.Io
Sent: Thursday, December 12, 2019 5:31 PM
Subject: Re: [edk2-discuss] Lock BootOrder variable


There are two other public, non-uefi spec solutions I am aware of.

1. Edk2 VariableLock protocol:;;sdata=avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg%3D&amp;reserved=0
A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.

2. Project Mu VariablePolicy protocol:;;sdata=14Wv%2B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c%3D&amp;reserved=0
Flexible policy based locking that can be implemented in various hardware architectures.

My team will be proposing the VariablePolicy protocol (potentially as a "code-first" effort) in the coming months and working to upstream this feature into edk2. The reality is some users and use cases want higher assurance for their platform settings and this can include the boot order. Doing this thru a well-defined and auditable protocol is better than an ad-hoc solutions. As you know locking some variables may break assumptions (or spec definition) that other code may have but that tradeoff is best evaluated by the use case.


-----Original Message-----
From: <> On Behalf Of Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
Subject: [EXTERNAL] Re: [edk2-discuss] Lock BootOrder variable

The UEFI define the BootOrder variable with NV+BS+RT attributes, so its not possible to lock this variable, you can try to delete the BootOrder variable and then set the variable with AT attribute, which will probably will result in an undefined behavior. OVMF just recreates the the BootOrder with NV+BS+RT again, then any code which can call Runtime Services will be able to change BootOrder again.

A possible method is too use a signed loader which have your own 'BootOrder' hardcoded.

-----Original Message-----
From: Samer El-Haj-Mahmoud []
Sent: Friday, December 13, 2019 12:30 AM
To:; Wang, Sunny (HPS SW) <>
Cc: Spottswood, Jason <>; Wiginton, Scott <>; Bodner, James <>; Haskell, Darrell <>
Subject: RE: [edk2-discuss] Lock BootOrder variable


Looks like this is a Windows Hardware Compatibility Specification requirement: , in Systems.pdf, under System.Fundamentals.Security.DGCG.DeviceGuard - Firmware BIOS lockdown

I am aware of some proprietary implementations of "Lock Boot Order" as a firmware/UEFI setting, but not a standard method defined in the spec.

Also, NSA has some guidelines on locking down UEFI boot order using whatever firmware settings to disable any undesired boot sources (such as externally available USB or network ports):;;sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&amp;reserved=0= .


Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu:
Hi All,

Is there any spec'd way that we can use to lock some UEFI variables like BootOrder without breaking OS installation and OS functionalities?

For some security reasons and customer use cases, we need to let system firmware completely own some UEFI variables like BootOrder. In other words, we don't want some UEFI variables to be controlled by the OS using the UEFI runtime service SetVariable. In addition, we tried to lock the BootOrder variable, but it would break OS installation or some OS functionalities.

By the way, we will bring this need to USWG if there is no existing spec'd way for satisfying this need.

Sunny Wang

Join to automatically receive all group messages.