Date
1 - 1 of 1
Platform Variable hook library for Supporting UEFI Variable Resiliency
Wang, Sunny (HPS SW)
Hi all,
As the discussion in the email thread below, we would like to add a Platform Variable hook library for IBV/OEM to support the UEFI Variable Resiliency (protection, detection, and recovery for critical UEFI variable).
For your quick reference, I summarized the reasons why we need to do this below:
1. There are some guidelines and requirements in NIST 800-193 and other security guidelines for critical UEFI variables like BootOrder, so we need to make some changes to comply with them.
2. The current variable protection mechanism in EDK2 called "Variable Policy (EDKII_VARIABLE_LOCK_PROTOCOL and VarCheckLib)" can't satisfy our needs. Using VariableLock would cause issues with OSes, and VarCheckLib can't check the data. Therefore, we need to add code to check and override the changes that were made at runtime.
3. Since each platform has its defined critical data and its protection and recovery policies/actions, some changes need to be platform-specific. However, there is no hook function or interface consumed by the EDK2 variable driver for IBV/OEM to add platform changes. Therefore, we need to add a Platform Variable hook library.
Moreover, I checked this with Ray and will bring the details to this week's design meeting on 2/21. I also uploaded my slides to the link below for your further reference. Of course, if you have any questions, feel free to bring it to me anytime.
https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%20Resiliency.pdf
Regards,
Sunny Wang
toggle quoted message
Show quoted text
As the discussion in the email thread below, we would like to add a Platform Variable hook library for IBV/OEM to support the UEFI Variable Resiliency (protection, detection, and recovery for critical UEFI variable).
For your quick reference, I summarized the reasons why we need to do this below:
1. There are some guidelines and requirements in NIST 800-193 and other security guidelines for critical UEFI variables like BootOrder, so we need to make some changes to comply with them.
2. The current variable protection mechanism in EDK2 called "Variable Policy (EDKII_VARIABLE_LOCK_PROTOCOL and VarCheckLib)" can't satisfy our needs. Using VariableLock would cause issues with OSes, and VarCheckLib can't check the data. Therefore, we need to add code to check and override the changes that were made at runtime.
3. Since each platform has its defined critical data and its protection and recovery policies/actions, some changes need to be platform-specific. However, there is no hook function or interface consumed by the EDK2 variable driver for IBV/OEM to add platform changes. Therefore, we need to add a Platform Variable hook library.
Moreover, I checked this with Ray and will bring the details to this week's design meeting on 2/21. I also uploaded my slides to the link below for your further reference. Of course, if you have any questions, feel free to bring it to me anytime.
https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%20Resiliency.pdf
Regards,
Sunny Wang
-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Wang, Sunny (HPS SW)
Sent: Thursday, February 6, 2020 4:52 PM
To: discuss@edk2.groups.io; lersek@...; sean.brogan@...; tim.lewis@...; phlamorim@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; ray.ni@...
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell <darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>; Javier Martinez Canillas <javierm@...>; Peter Jones <pjones@...>; Wang, Sunny (HPS SW) <sunnywang@...>
Subject: Re: [edk2-discuss] Lock BootOrder variable
Hi Lazlo,
Thanks for the comments and sorry for the delay. I was just back from my long vacation and was busy with some other stuff.
Yeah, locking BootOrder is not acceptable, so we would like to override or ignore the BootOrder change made by OS or non-trusted software at the next boot to protect and recover the BootOrder. In other words, locking variables will definitely not be used as a solution. We just want OS vendors to gracefully deal with all the error status from the runtime variable service. However, if you think RuntimeServicesSupported is good and clear enough for OS vendors to gracefully deal with this, I'm totally fine with not adding another description into UEFI specification.
As for the solution, you're also right about that it should be implemented as a platform code. However, since the system may have more UEFI variables (not only BootOrder) that are identified as critical data and needed to be protected as well, we would like to propose a platform variable hook library to add the hook function calls into the variable driver for IBV/OEM like us to implement the platform protection code.
Moreover, before submitting my patches, I think it would be better to further discuss this at the design meeting, so I will check this with Ray to find an available time slot and then present the details to you guys. The purpose of our proposal will be to have platform libraries for IBV/OEM to implement their code for complying with the NIST 800-193 and other security guidelines mentioned in the previous emails (Supporting the UEFI Variable Resiliency (protection, detection, and recovery)).
Regards,
Sunny Wang
-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Saturday, January 4, 2020 1:48 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@...>; sean.brogan@...; tim.lewis@...; phlamorim@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell <darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>; Javier Martinez Canillas <javierm@...>; Peter Jones <pjones@...>
Subject: Re: [edk2-discuss] Lock BootOrder variable
On 12/18/19 11:03, Wang, Sunny (HPS SW) wrote:
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.
Laszlo
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Wang, Sunny (HPS SW)
Sent: Thursday, February 6, 2020 4:52 PM
To: discuss@edk2.groups.io; lersek@...; sean.brogan@...; tim.lewis@...; phlamorim@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; ray.ni@...
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell <darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>; Javier Martinez Canillas <javierm@...>; Peter Jones <pjones@...>; Wang, Sunny (HPS SW) <sunnywang@...>
Subject: Re: [edk2-discuss] Lock BootOrder variable
Hi Lazlo,
Thanks for the comments and sorry for the delay. I was just back from my long vacation and was busy with some other stuff.
Yeah, locking BootOrder is not acceptable, so we would like to override or ignore the BootOrder change made by OS or non-trusted software at the next boot to protect and recover the BootOrder. In other words, locking variables will definitely not be used as a solution. We just want OS vendors to gracefully deal with all the error status from the runtime variable service. However, if you think RuntimeServicesSupported is good and clear enough for OS vendors to gracefully deal with this, I'm totally fine with not adding another description into UEFI specification.
As for the solution, you're also right about that it should be implemented as a platform code. However, since the system may have more UEFI variables (not only BootOrder) that are identified as critical data and needed to be protected as well, we would like to propose a platform variable hook library to add the hook function calls into the variable driver for IBV/OEM like us to implement the platform protection code.
Moreover, before submitting my patches, I think it would be better to further discuss this at the design meeting, so I will check this with Ray to find an available time slot and then present the details to you guys. The purpose of our proposal will be to have platform libraries for IBV/OEM to implement their code for complying with the NIST 800-193 and other security guidelines mentioned in the previous emails (Supporting the UEFI Variable Resiliency (protection, detection, and recovery)).
Regards,
Sunny Wang
-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Saturday, January 4, 2020 1:48 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@...>; sean.brogan@...; tim.lewis@...; phlamorim@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell <darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>; Javier Martinez Canillas <javierm@...>; Peter Jones <pjones@...>
Subject: Re: [edk2-discuss] Lock BootOrder variable
On 12/18/19 11:03, Wang, Sunny (HPS SW) wrote:
Hi Sean,Locking the boot order by way of causing SetVariable to fail for the OS seems wrong to me.
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
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.
Laszlo
-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf
Of Sean via Groups.Io
Sent: Wednesday, December 18, 2019 4:55 AM
To: Wang, Sunny (HPS SW) <sunnywang@...>; tim.lewis@...;
discuss@edk2.groups.io; phlamorim@...; Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@...>
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell
<darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>
Subject: Re: [edk2-discuss] Lock BootOrder variable
Sunny,
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?
Thanks
Sean
-----Original Message-----
From: Wang, Sunny (HPS SW) <sunnywang@...>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@...; discuss@edk2.groups.io; Sean Brogan
<sean.brogan@...>; phlamorim@...; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Cc: Spottswood, Jason <jason.spottswood@...>; Haskell, Darrell
<darrell.haskell@...>; Wiginton, Scott <scott.wiginton@...>;
Wang, Sunny (HPS SW) <sunnywang@...>
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.
-
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fedk2.groups.io-252F
g-252Fdevel-252Ffiles-252FDesigns-252F2019-252F0516-26amp-3Bdata-3D02-
257C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77
faa2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241
153980473-26amp-3Bsdata-3DxjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ-
253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMd
GZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii
_NieuwsJZk8&s=6O-ZcjoIEhjvpzBGydrRy4RM6BCiLwpTVRmAlkphX-o&e=
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.
Regards,
Sunny Wang
-----Original Message-----
From: tim.lewis@... [mailto:tim.lewis@...]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@...;
phlamorim@...; Wang, Sunny (HPS SW) <sunnywang@...>
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.
Thanks,
Tim
-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Sean via Groups.Io
Sent: Thursday, December 12, 2019 5:31 PM
To: discuss@edk2.groups.io; phlamorim@...; sunnywang@...
Subject: Re: [edk2-discuss] Lock BootOrder variable
Sunny,
There are two other public, non-uefi spec solutions I am aware of.
1. Edk2 VariableLock protocol:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Ftian
ocore-252Fedk2-252Fblob-252Fmaster-252FMdeModulePkg-252FInclude-252FPr
otocol-252FVariableLock.h-26amp-3Bdata-3D02-257C01-257Csean.brogan-254
0microsoft.com-257C7a27e3cc7d754208afd108d77faa2a64-257C72f988bf86f141
af91ab2d7cd011db47-257C1-257C0-257C637118241153980473-26amp-3Bsdata-3D
avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg-253D-26amp-3Breserved-3D0&
d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f
8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii_NieuwsJZk8&s=ACauqOvz9A5G
8S3vH-bALwc4RPyfS1u8O2sza1_9Hbw&e=
A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.
2. Project Mu VariablePolicy protocol:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fmicr
osoft-252Fmu-5Fbasecore-252Fblob-252Frelease-252F201911-252FMdeModuleP
kg-252FInclude-252FProtocol-252FVariablePolicy.h-26amp-3Bdata-3D02-257
C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77faa
2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241153
980473-26amp-3Bsdata-3D14Wv-252B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c
-253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEM
dGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71I
i_NieuwsJZk8&s=xjXKoZxYjZwyWJrEHGS5jayMp6HNXhombPuvq7NNM8g&e=
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.
Thanks
Sean
-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
To: discuss@edk2.groups.io; sunnywang@...
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 [mailto:Samer.El-Haj-Mahmoud@...]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@...>
Cc: Spottswood, Jason <jason.spottswood@...>; Wiginton, Scott
<scott.wiginton@...>; Bodner, James <james.bodner@...>;
Haskell, Darrell <darrell.haskell@...>
Subject: RE: [edk2-discuss] Lock BootOrder variable
Sunny,
Looks like this is a Windows Hardware Compatibility Specification
requirement: https://go.microsoft.com/fwlink/?linkid=2086856 , 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): https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.nsa.gov_Portals_70_documents_what-2Dwe-2Ddo_cybersecurity_professional-2Dresources_csi-2Duefi-2Dlockdown.pdf%26d%3DDwIFAg%26c%3DC5b8zRQO1miGmBeVZ2LFWg%26r%3DZ9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw%26m%3DasfixhAVUFNND_WEH4KyE0iVEY8HgOOvdPb6NrNwOUQ%26s%3D-rAbAKmK6iJFSGCadTldga_88zXzHJY2rz7Zmyh_lSM%26e&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&reserved=0= .
Thanks,
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.
Regards,
Sunny Wang