Date
1 - 16 of 16
Lock BootOrder variable
|
Wang, Sunny (HPS SW)
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 |
|
|
|
Samer El-Haj-Mahmoud
Sunny,
toggle quoted message
Show quoted text
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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, --Samer -----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Wang, Sunny (HPS SW) via Groups.Io Sent: Thursday, December 12, 2019 3:50 AM To: discuss@edk2.groups.io Cc: Wang, Sunny (HPS SW) <sunnywang@...>; Spottswood, Jason <jason.spottswood@...>; Wiginton, Scott <scott.wiginton@...>; Bodner, James <james.bodner@...>; Haskell, Darrell <darrell.haskell@...> Subject: [edk2-discuss] Lock BootOrder variable 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. |
|
|
|
Paulo Henrique Lacerda de Amorim
The UEFI define the BootOrder variable with NV+BS+RT attributes, so its
toggle quoted message
Show quoted text
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. Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Sean
Sunny,
toggle quoted message
Show quoted text
There are two other public, non-uefi spec solutions I am aware of. 1. Edk2 VariableLock protocol: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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. Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Tim Lewis
Sean --
toggle quoted message
Show quoted text
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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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. Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Wang, Sunny (HPS SW)
Thanks, guys.
toggle quoted message
Show quoted text
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. - https://edk2.groups.io/g/devel/files/Designs/2019/0516 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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Tim Lewis
Sunny --
toggle quoted message
Show quoted text
I am curious. Can you point me to the portion of the NIST 800-193 that has guidelines the UEFI boot order (or similar data)? Is this a case when the owner of the platform is not the user of the platform? Thanks, Tim -----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@...; 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: 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. - https://edk2.groups.io/g/devel/files/Designs/2019/0516 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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Sean
Sunny,
toggle quoted message
Show quoted text
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. - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2019%2F0516&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&reserved=0 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: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FMdeModulePkg%2FInclude%2FProtocol%2FVariableLock.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg%3D&reserved=0 A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fblob%2Frelease%2F201911%2FMdeModulePkg%2FInclude%2FProtocol%2FVariablePolicy.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=14Wv%2B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c%3D&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. 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, |
|
|
|
Wang, Sunny (HPS SW)
Hi Tim,
toggle quoted message
Show quoted text
You can check the section 2.2.2.1 Critical Data. The Boot order is identified as critical data that should be protected. Yes, we can see this case on server platforms (enterprise solution and service provider) Regards, Sunny Wang -----Original Message-----
From: tim.lewis@... [mailto:tim.lewis@...] Sent: Wednesday, December 18, 2019 3:42 AM To: Wang, Sunny (HPS SW) <sunnywang@...>; discuss@edk2.groups.io; sean.brogan@...; 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 -- I am curious. Can you point me to the portion of the NIST 800-193 that has guidelines the UEFI boot order (or similar data)? Is this a case when the owner of the platform is not the user of the platform? Thanks, Tim -----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@...; 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: 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. - https://edk2.groups.io/g/devel/files/Designs/2019/0516 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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Wang, Sunny (HPS SW)
Hi Sean,
toggle quoted message
Show quoted text
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 status from the runtime variable service). Regards, Sunny Wang -----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. - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2019%2F0516&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&reserved=0 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: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FMdeModulePkg%2FInclude%2FProtocol%2FVariableLock.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg%3D&reserved=0 A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fblob%2Frelease%2F201911%2FMdeModulePkg%2FInclude%2FProtocol%2FVariablePolicy.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=14Wv%2B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c%3D&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. 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, |
|
|
|
Tim Lewis
Sunny --
toggle quoted message
Show quoted text
Thanks for the clarification. Tim -----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Wang, Sunny (HPS SW) Sent: Wednesday, December 18, 2019 1:45 AM To: tim.lewis@...; discuss@edk2.groups.io; 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: Re: [edk2-discuss] Lock BootOrder variable Hi Tim, You can check the section 2.2.2.1 Critical Data. The Boot order is identified as critical data that should be protected. Yes, we can see this case on server platforms (enterprise solution and service provider) Regards, Sunny Wang -----Original Message----- From: tim.lewis@... [mailto:tim.lewis@...] Sent: Wednesday, December 18, 2019 3:42 AM To: Wang, Sunny (HPS SW) <sunnywang@...>; discuss@edk2.groups.io; sean.brogan@...; 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 -- I am curious. Can you point me to the portion of the NIST 800-193 that has guidelines the UEFI boot order (or similar data)? Is this a case when the owner of the platform is not the user of the platform? Thanks, Tim -----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@...; 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: 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. - https://edk2.groups.io/g/devel/files/Designs/2019/0516 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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Wang, Sunny (HPS SW)
No problem. Thanks for looking into this, Tim. :)
toggle quoted message
Show quoted text
-----Original Message-----
From: tim.lewis@... <tim.lewis@...> Sent: Thursday, December 19, 2019 1:03 AM To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@...>; sean.brogan@...; 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 -- Thanks for the clarification. Tim -----Original Message----- From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Wang, Sunny (HPS SW) Sent: Wednesday, December 18, 2019 1:45 AM To: tim.lewis@...; discuss@edk2.groups.io; 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: Re: [edk2-discuss] Lock BootOrder variable Hi Tim, You can check the section 2.2.2.1 Critical Data. The Boot order is identified as critical data that should be protected. Yes, we can see this case on server platforms (enterprise solution and service provider) Regards, Sunny Wang -----Original Message----- From: tim.lewis@... [mailto:tim.lewis@...] Sent: Wednesday, December 18, 2019 3:42 AM To: Wang, Sunny (HPS SW) <sunnywang@...>; discuss@edk2.groups.io; sean.brogan@...; 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 -- I am curious. Can you point me to the portion of the NIST 800-193 that has guidelines the UEFI boot order (or similar data)? Is this a case when the owner of the platform is not the user of the platform? Thanks, Tim -----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@...; 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: 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. - https://edk2.groups.io/g/devel/files/Designs/2019/0516 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: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h 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://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All, |
|
|
|
Laszlo Ersek
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. 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----- |
|
|
|
Laszlo Ersek
On 01/03/20 18:48, Laszlo Ersek wrote:
Furthermore, we already have RuntimeServicesSupported, for exposingJust because I mentioned RuntimeServicesSupported, I guess it makes sense to reference this spec ticket too: https://mantis.uefi.org/mantis/view.php?id=2049 Thanks Laszlo |
|
|
|
Wang, Sunny (HPS SW)
Hi Lazlo,
toggle quoted message
Show quoted text
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. 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----- |
|
|
|
Bret Barkelew <bret.barkelew@...>
Sunny,
Have you seen the work that we've proposed on the VariablePolicy RFC (in the devel and rfc mailing groups)? Would that work for your purposes? Thanks! - Bret |
|
|