Date   

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.

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@hpe.com>; tim.lewis@insyde.com; discuss@edk2.groups.io; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; Sean Brogan <sean.brogan@microsoft.com>; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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&amp;sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&amp;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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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&amp;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: 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&amp;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.

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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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&amp;sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&amp;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


Re: Examples opening and reading/writing a file with EDK2

alejandro.estay@...
 

Thank you very much Laszlo, and Happy New Year.

There's still some problems. Apparently the optimizer is stripping out the fixed array that I'm using to save and print the text file. I know that this is not "best practice" (Untyped allocation is the standard here, I guess), however is working printing the file successfully using the NOOPT target, so I think that there's something in the DEBUG target that I don't know.
The suspicious behaviour occurs when I ask charptr variable after saving the fixed array address, it remains in 0

charptr=&buffer_char[0];

as initialized. What are the differences between DEBUG and NOOPT towards generated debug information?

Added some screenshots. Text output with debug case prints just spaces.


Re: Examples opening and reading/writing a file with EDK2

Laszlo Ersek
 

On 12/31/19 21:38, alejandro.estay@gmail.com wrote:

EFI_STATUS EFIAPI UefiMain (IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable)
{
//DEBUG ((EFI_D_INFO, "My Entry point: 0x%08x\r\n", (CHAR16*)UefiMainMySampleApp ) );
Print(L"abriendo archivo...\n");
EFI_HANDLE_PROTOCOL HandleProtocol = SystemTable->BootServices->HandleProtocol;
call_status = HandleProtocol(ImageHandle, &gEfiLoadedImageProtocolGuid, (void**)&LoadedImage);
call_status = HandleProtocol(LoadedImage->DeviceHandle, &gEfiSimpleFileSystemProtocolGuid, (void**)&FileSystem);
FileSystem->OpenVolume(FileSystem, &Root);
(Side comment: please always check the returns status.)

call_status = Root->Open(Root, &text_file, L"text_img", EFI_FILE_MODE_READ, EFI_FILE_READ_ONLY);
if (call_status != EFI_SUCCESS)
{
SystemTable->ConOut->OutputString(SystemTable->ConOut, L"imagen no encontrada\r\n");
return call_status;
}
else
{
call_status=ChangeFrequency(EFI_DEFAULT_BEEP_ALTFREQUENCY);

GenerateBeep();

SystemTable->ConOut->OutputString(SystemTable->ConOut, L"leyendo\r\n");


call_status=Root->Read(text_file, &buffer_siz, &image_text);
This call looks invalid (undefined behavior), likely due to a copy/paste
error. It should be:

text_file->Read (text_file, ...)
^^^^^^^^^ ^^^^^^^^^

and not

Root->Read (text_file, ...)
^^^^ ^^^^^^^^^

HTH,
Laszlo



SystemTable->ConOut->OutputString(SystemTable->ConOut, image_text);
}

return EFI_SUCCESS;
}


Re: Examples opening and reading/writing a file with EDK2

alejandro.estay@...
 

Hi I've wrote another little program trying to focus on this (it was added into MdeModulePkg)
------------------------------------------------------------------------------------------------------------------------------
#include <Uefi.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiLib.h>
#include <Guid/FileInfo.h>
#include <Protocol/LoadedImage.h>
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/IoLib.h>



// Piezo speaker related
#define EFI_SPEAKER_CONTROL_PORT 0x61
#define EFI_SPEAKER_OFF_MASK 0xFC
#define EFI_BEEP_ON_TIME_INTERVAL 0x50000
#define EFI_BEEP_OFF_TIME_INTERVAL 0x50000

#define EFI_TIMER_CONTROL_PORT 0x43
#define EFI_TIMER_CONTROL2_PORT 0x42

#define EFI_DEFAULT_BEEP_NUMBER 1
#define EFI_DEFAULT_BEEP_ON_TIME 0x50000
#define EFI_DEFAULT_BEEP_OFF_TIME 0x50000
#define EFI_DEFAULT_BEEP_FREQUENCY 0x500
#define EFI_DEFAULT_BEEP_ALTFREQUENCY 0x1500

#define I8254_CTRL_SEL_CTR(x) ((x) << 6)
#define I8254_CTRL_RW(x) (((x) & 0x3) << 4)
#define I8254_CTRL_LATCH I8254_CTRL_RW(0)
#define I8254_CTRL_REG 0x03
#define I8254_CTRL_LSB_MSB I8254_CTRL_RW(3)



/**
as the real entry point for the application.

@param[in] ImageHandle The firmware allocated handle for the EFI image.
@param[in] SystemTable A pointer to the EFI System Table.

@retval EFI_SUCCESS The entry point is executed successfully.
@retval other Some error occurs when executing this entry point.

**/
EFI_STATUS call_status;
//EFI_GUID gEfiSimpleFileSystemProtocolGuid = EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
EFI_GUID gEfiFileInfoGuid = EFI_FILE_INFO_ID;
EFI_GUID gEfiLoadedImageProtocolGuid = EFI_LOADED_IMAGE_PROTOCOL_GUID;

EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *FileSystem;



EFI_FILE *Root;
EFI_FILE *text_file;
//CHAR16 *image_text={L"oe\r\n"};
CHAR16 image_text[21]={};
UINTN buffer_siz=21;

int index;




VOID turn_spkr_on( VOID )
{
UINT8 Data;

Data = IoRead8( EFI_SPEAKER_CONTROL_PORT );
Data |= 0x03;
IoWrite8( EFI_SPEAKER_CONTROL_PORT, Data) ;
}


VOID turn_spkr_off( VOID )
{
UINT8 Data;

Data = IoRead8( EFI_SPEAKER_CONTROL_PORT );
Data &= EFI_SPEAKER_OFF_MASK;
IoWrite8( EFI_SPEAKER_CONTROL_PORT, Data );
}


VOID GenerateBeep( VOID )
{

turn_spkr_on();
gBS->Stall( EFI_BEEP_ON_TIME_INTERVAL );
turn_spkr_off();
gBS->Stall( EFI_BEEP_OFF_TIME_INTERVAL );

}


EFI_STATUS ChangeFrequency( UINT16 Frequency )
{
UINT8 Data;

Data = 0xB6;
IoWrite8(EFI_TIMER_CONTROL_PORT, Data);

Data = (UINT8)(Frequency & 0x00FF);
IoWrite8( EFI_TIMER_CONTROL2_PORT, Data );
Data = (UINT8)((Frequency & 0xFF00) >> 8);
IoWrite8( EFI_TIMER_CONTROL2_PORT, Data );

return EFI_SUCCESS;
}


EFI_STATUS EFIAPI UefiMain (IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable)
{
//DEBUG ((EFI_D_INFO, "My Entry point: 0x%08x\r\n", (CHAR16*)UefiMainMySampleApp ) );
Print(L"abriendo archivo...\n");
EFI_HANDLE_PROTOCOL HandleProtocol = SystemTable->BootServices->HandleProtocol;
call_status = HandleProtocol(ImageHandle, &gEfiLoadedImageProtocolGuid, (void**)&LoadedImage);
call_status = HandleProtocol(LoadedImage->DeviceHandle, &gEfiSimpleFileSystemProtocolGuid, (void**)&FileSystem);
FileSystem->OpenVolume(FileSystem, &Root);
call_status = Root->Open(Root, &text_file, L"text_img", EFI_FILE_MODE_READ, EFI_FILE_READ_ONLY);
if (call_status != EFI_SUCCESS)
{
SystemTable->ConOut->OutputString(SystemTable->ConOut, L"imagen no encontrada\r\n");
return call_status;
}
else
{
call_status=ChangeFrequency(EFI_DEFAULT_BEEP_ALTFREQUENCY);

GenerateBeep();

SystemTable->ConOut->OutputString(SystemTable->ConOut, L"leyendo\r\n");


call_status=Root->Read(text_file, &buffer_siz, &image_text);


SystemTable->ConOut->OutputString(SystemTable->ConOut, image_text);
}

return EFI_SUCCESS;
}
---------------------------------------
When I pass over read, GDB reports that image_text is 0. If I understood this, I believe that Read() must place the address of the first of the read elements from the file (20 elements). The file appears to be properly opened (i have the QEMU OVMF log also), but I'm failing reading it and the pointer variable is not being filled (or I'm confusing it).

I'm kinda rookie with C and pointer notation still confuses me sometimes.
Thanks for your answers

Here's the QEMU OVMF log tail
FSOpen: Open '\boot2.efi' Success
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)/\boot2.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 6F328A8
Loading driver at 0x00006AF5000 EntryPoint=0x00006AF626A boot2.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 6F66E90
ProtectUefiImageCommon - 0x6F328A8
- 0x0000000006AF5000 - 0x0000000000002000
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 7EA9AA0
FSOpen: Open 'text_img' Success
FSOpen: Open '\' Success


UEFI Development Kit Debugger Tool with USB 3.0

Satoshi Tanda
 

Hi,

I am new to UEFI development and trying to set up physical machine
debugging environment using UEFI Development Kit Debugger Tool (UDK) but
unsuccessful so far. Can someone assist me to figure out what I am missing?

In short, I am trying to follow a scenarios explained as "Debugging a
standalone module loaded in a UEFI shell" through USB 3.0 with Windbg, but
the debugger never establishes connection with the target even after
loading DebugAgentDxe.dxe.

Here is some information on my setup and steps of attempts.

Debugger:
- Windows 10 x64
- UDK 1.5. Configured as below
----
[Debug Port]
Channel = USB
----
- Windbg 10.0.18362.1 (x86)
- USB 3.0 cable connected through a USB-C-to-A adapter

Target:
- ASUS UX360C, BIOS version 2.17.1249 (the latest I can get)
- Connected through USB-A port directly

Workflow:
1. Insert the USB thumb drive to the target
This USB drive contains the UEFI shell taken from the EDK2
repo, DebugAgentDxe.efi compiled as below, and a test DXE driver with int3
at the entry point.
build -p SourceLevelDebugPkg\SourceLevelDebugPkg.dsc -m
SourceLevelDebugPkg/DebugAgentDxe/DebugAgentDxe.inf -a X64 -D
SOURCE_DEBUG_USE_USB3

2. Boot the target system into the UEFI shell

3. Load DebugAgentDxe.efi in the USB drive
load DebugAgentDxe.efi
This results in either
- a) never returning to the shell (hang). "USB Debug Connection Device"
appearing in Device Manager on the Debugger side, or
- b) returning and "USB Debug Connection Device" not appearing

Starting UDK's SoftDebugger + Windbg does not seem to change, regardless of
whether that is done before or after (3). Windbg prints this
```
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.
WARNING: An old EXDIv1 server has been detected. Debugger will use the
compatibility layer.
It is advised to rebuild your EXDI server using EXDIv3 interfaces.
```
SoftDebugger Console shows this
```
Intel(R) UEFI Development Kit Debugger Tool Version 1.5.0
Debugging through USB (\\?\USB2DBG)
Redirect Target output to TCP port (20715)
```

4. In case the system did not freeze after (3), load the test driver to
execute int3. System hangs.

Debugging through USB 3 is possible as far as I read from the manual of
UDK, and this training material. So I am lost as to what the problem is.
https://gitpitch.com/tianocore-training/EDK_II_UDK_Debugger_Pres/master#/11

Setup of Windbg & UDK is unlikely the issue as I was also able to debug the
DXE driver running on VirtualBox, although it was serial-based. Those
pieces of hardware are also unlikely a problem as I am able to debug the
Windows kernel using the same devices.

I also tried with Dell XPS 13 9360 but the results are the same. My best
guess is that the target's UEFI is somehow not compatible
with SourceLevelDebugPkg, but I would appreciate if anyone can review my
configurations and give me suggestion on setting up a debug environment
with physical devices.

Thank you for your help in advance.

Best,
Satoshi


Re: Lock BootOrder variable

Wang, Sunny (HPS SW)
 

No problem. Thanks for looking into this, Tim. :)

-----Original Message-----
From: tim.lewis@insyde.com <tim.lewis@insyde.com>
Sent: Thursday, December 19, 2019 1:03 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Wednesday, December 18, 2019 3:42 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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,

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




Re: Does EmulatorPkg support source-level debug?

Yeh
 


Re: Lock BootOrder variable

Tim Lewis
 

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@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Wednesday, December 18, 2019 3:42 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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,

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




Re: Does EmulatorPkg support source-level debug?

Liming Gao
 

I build and run Emulator with below command.

edksetup.bat Rebuild
build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -a IA32
cd Build\EmulatorIA32\DEBUG_VS2017\IA32
type WinHost.exe

Thanks
Liming

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Yeh
Sent: Wednesday, December 18, 2019 10:15 AM
To: Gao; Gao, Liming <liming.gao@intel.com>; discuss@edk2.groups.io
Subject: Re: [edk2-discuss] Does EmulatorPkg support source-level debug?

Hi Liming,

Thanks for the information.
But may I know how to do that in VS?

Is it possible to build the EDK2 by the VS?
Now I am building it by the Windows command line.


Re: Lock BootOrder variable

Wang, Sunny (HPS SW)
 

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 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@hpe.com>; tim.lewis@insyde.com; discuss@edk2.groups.io; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; Sean Brogan <sean.brogan@microsoft.com>; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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&amp;sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&amp;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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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&amp;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: 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&amp;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.

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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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&amp;sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&amp;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




Re: Lock BootOrder variable

Wang, Sunny (HPS SW)
 

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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Wednesday, December 18, 2019 3:42 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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,

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




Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Ni, Ray
 

Sunny,
Thanks for your comments.

Thanks,
Ray

-----Original Message-----
From: Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Sent: Wednesday, December 18, 2019 11:54 AM
To: discuss@edk2.groups.io; ashishsingha@nvidia.com; Jeff Brasen <jbrasen@nvidia.com>; Ni, Ray <ray.ni@intel.com>;
devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com
Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Subject: RE: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Sorry for the delay. Somehow I didn't catch the follow-up email. Thanks for checking my comments, Ray and Ashish.
Yeah, agree. 2.b is better. I will review the code change.

Regards,
Sunny Wang

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Ashish Singhal
Sent: Wednesday, December 18, 2019 4:16 AM
To: Jeff Brasen <jbrasen@nvidia.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo Ersek
<lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>;
Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration

I have submitted a patch based on 2.b as suggested by Ray. I am open to making changes in the structure of the protocol
functions as well as the verbal description. Please let me know what you all think about it.

Thanks
Ashish
________________________________
From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Thursday, December 12, 2019 10:52 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>;
afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Thanks for the summary Ray, for the problem summary only thing I would add would be that platform also wants to
create/modify boot options when full enumeration is requested as well.

For solutions I prefer option 2 as we don't have to put the same logic everywhere of how to modify the default
enumerated list. And if we do that 2b makes more sense as then we don't have to modify all of the existing platforms.

I see two things the platform would need to do.

1. Update list created in BmEnumerateBootOptions
2. Delete any no longer valid platform created boot options


Thanks,

Jeff

________________________________
From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, December 11, 2019 7:00 AM
To: Jeff Brasen <jbrasen@nvidia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>;
afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

External email: Use caution opening links or attachments


Jeff,

Tom from AMD booked the meeting for SEV discussion months ago. I am afraid there is no time for this discussion.

Let's try to resolve it in mails.



Firstly, let me rephase the problem and your proposed solutions here (subjective + verb + objective). Sunny's input is also
included. Hope Mike K and others can provide inputs.

Personally, I agree with 2.b. It helps us to gradually migrate the PlatformBootManagerLib to PlatformBootManager
protocol. Protocol with Revision field helps to reduce the impact to old platforms with new APIs added.



**Problem:

Platform requires certain BlockIo/SimpleFileSystem/LoadFile instances don't cause Boot#### created. It's a need
of platform customization.



**Details:

Boot#### for BlockIo/SimpleFileSystem/LoadFile are created by API EfiBootMangerRefreshAllBootOptions(). There
are 2 places that call this API:

1. Platform Boot Manager calls the API (usually in the full configuration boot path)
2. UiApp calls the API when entering "Boot Manager" page and "Boot Maintenance Manager" page.



Platform can change Platform Boot Manager to remove the unneeded Boot#### in case #1.

But platform has no way to remove the Boot#### created in case #2 .



**Potential solutions:

1. Update UiApp
* Define a new PCD and a new event group.

If PCD is TRUE, UiApp signals the event. Event callback creates the Boot####. Otherwise,
EfiBootManagerRefreshAllBootOptions() is called.

* Add a new PlatformBootManagerLib API (implemented by platform).

UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (need to coordinate rollout with updates to all
platforms).

* Add a new protocol (implemented by platform).

UiApp calls the new protocol if it exists otherwise calls EfiBootManagerRefreshAllBootOption.



1. Update EfiBootManagerRefreshAllBootOptions()
* Add a new library class (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new library class.

* Add a new PlatformBootManager protocol (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists.



Thanks,

Ray



From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com;
discuss@edk2.groups.io
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Can we discuss this at the design meeting this week (12/12)?



Thanks,

Jeff

________________________________

From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>;
afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Yes, I think that would be good.



Summarizing everything in this thread



Problem: Platform needs to customize the boot options, this can be done for normal boot but the UiApp calls
EfiBootManagerRefreshAllBootOption in a couple places.



Potential solutions:

1 - Define new PCD and event group if PCD is set true then signal event instead of calling
EfiBootManagerRefreshAllBootOption in UiApp

2 - Add new function to boot manager library and replace call to EfiBootManagerRefreshAllBootOption in UiApp (need to
coordinate rollout with updates to all platform.

3 - Add new protocol with new function, if supported call this otherwise call EfiBootManagerRefreshAllBootOption as is
done now

4 - For 2/3 use generic function so we don't need new APIs for future expansion

5 - Update EfiBootManagerRefreshAllBootOption to call platform specific function.



Thanks,
Jeff





From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>;
Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

I think it's a good topic that we could discuss in the open design meeting.

Are you ok to present the problem you have and discuss the potential solutions in that meeting?

https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
Behalf Of Jeff Brasen
Sent: Thursday, November 14, 2019 2:43 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo
Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Thinking about this more I think we could do this with a PCD and a new group event without having to define any new
function interfaces.



We could change UiApp and BootManagerMenuApp (and any others that are relevant) from



EfiBootManagerRefreshAllBootOption ();



to



if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

EFI_EVENT Event;

gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid, &Event );

gBS->SignalEvent (Event);

gBS->CloseEvent (Event);

} else {

EfiBootManagerRefreshAllBootOption ();

}



Then a platform that wants to do this on its own would just set this pcd and create a group event and do what it needs to
do there.



Thanks,

Jeff

________________________________

From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: Monday, November 11, 2019 5:00 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>;
afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



I am not sure a PCD would work (unless I am missing something) We do want to do a connect all and re-enumerate in
UiApp but we need the platform code to be involved in that process.



Thanks,

Jeff

________________________________

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Monday, November 11, 2019 4:58 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Jeff
Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

If adding a PCD to control UiApp can meet the real needs, I prefer to do in that way instead of adding new APIs to
PlatformBootManagerLib.



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On
Behalf Of Jeff Brasen
Sent: Tuesday, November 12, 2019 6:58 AM
To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>;
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



If we are concerned about deploying this and breaking builds we could do this via a new protocol instead. In that case
though we would leave the old default behavior in the code to handle platforms that didn't implement the new protocol,
so this might not be the cleanest way to deploy this.



We could also look at adding a generic platform boot hook function (either as a library function or protocol) if we wanted
to limit the number of disruption on new customization hooks. Something like



EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *ContextData OPTIONAL)



Where Notification type describes where we are that we want platform to potentially handle and ContextData is per type
caller allocated data that provides additional in/out data. This has the same issue of leaving the current default behavior
in place for unsupported types as well as being a less than specific function to describe.



Thanks,

Jeff



________________________________

From: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
Sent: Friday, November 8, 2019 9:37 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>;
devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>;
afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>;
Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



On 11/07/19 18:46, Jeff Brasen wrote:
Fixing UiApp seems reasonable, I do think we would want a hook to the platform library in here as the enumeration that
occurs in the UiApp is intended to do a full enumeration of the system and there may be platform specifics to how that
occurs.

Fully agreed -- entering UiApp should expose everything bootable in the system, unless (perhaps) PlatformBootManagerLib
specifically thinks otherwise.

Of course, then we arrive (again) at the problem that a call in UefiBootManagerLib, to a *new* PlatformBootManagerLib
API, will break tens of out-of-tree platforms. :)

I think that can be prevented, as follows; but it will take quite some time:

- introduce the new function declaration in "PlatformBootManagerLib.h",
- modify all platforms (in tree and out of tree) to implement (define) the new function,
- call the new function from UefiBootManagerLib

For some history / background on this kind of problem, I suggest reading
through:

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.tianocore.org_show-5Fbug.cgi-3Fid-3D982&d=DwIF-
g&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=EzQH7xR5u0kejdb3Oa18jq
GGrV5AO_ROvd_Y_ajQQMk&s=cTZCJVE04A0qq4imb3Pma8jdJIrunDornyDXBty-1Uk&e=

Thanks,
Laszlo

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Thursday, November 7, 2019 12:21 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>;
afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Laszlo
Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael
D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration

I treat the issue in this way:

1. Platform Boot Manager library does a good job. It doesn't always call RefreshAll() API to auto-create the boot
options
2. But UiApp doesn't. It constantly call RefreshAll().

Do you think that we can fix UiApp instead? For example, introducing a PCD to control the boot option refresh behavior?

Thanks,
Ray

From:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gr
oups.io%3cmailto:devel@edk2.groups.io>>> On Behalf Of Jeff Brasen
Sent: Thursday, November 7, 2019 3:02 PM
To: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>; afish@apple.com<mailto:afish@apple.com>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration

The issue is there are some auto created options we do not want on our platform.
Get Outlook for
Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_gh
ei36&d=DwIF-g&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJ
UR24f8N3205AYw&m=EzQH7xR5u0kejdb3Oa18jqGGrV5AO_ROvd_Y_ajQQMk&s=yaH1ZcO
LL9iVBCGMBGKtuwgPVbblPxtJooJMnpxn8P0&e= >

________________________________
From: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Sent: Wednesday, November 6, 2019 11:59:31 PM
To: Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>;
afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gr
oups.io%3cmailto:devel@edk2.groups.io>>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration


Jeff,

RefreshAllBootOption() only modifies/creates the auto-created boot options. For the boot options created by platform
boot manager library, they stay with no one touches. And all auto-created boot options are appended in the end of boot
option list (through BootOrder).



From: Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>
Sent: Thursday, November 7, 2019 12:13 PM
To: afish@apple.com<mailto:afish@apple.com>; Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration



As the suggestions below made sense, we updated our platform boot manager library to behave in this manner and for
normal boots everything works well. However the UiApp and boot maintenance applications in EDK2 also call
EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu which will re-create the skipped boot options
with no place for the platform code to intervene.



What about a solution where we add a new Platform library function that allows for override of the behavior of
BmEnumerateBootOptions? For example, either a function or protocol that takes the same parameters as this function
and only if it returns NULL then we continue to the default enumeration code. Or a function call inserted at the end that
would modify the load option array after the system does the standard enumeration.



-Jeff



From: afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 9:20 AM
To: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Mike Kinney
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration



Ray,



Is there an obvious hook point we could point Jeff and Ashish at?



Long term it would be a good idea to have a Wiki page to give some guidance on how to customize the BDS.



Thanks,



Andrew Fish



On Nov 5, 2019, at 9:20 PM, Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>> wrote:



Andrew,

I agree with your opinion.

It's expected that Platform Boot Manager lib calls EfiBootManagerRefreshAllBootOption() only in full configuration boot
path.

The full configuration boot path is chosen when hardware changes
happen. So it's not expected EfiBootManagerRefresh...() be called in every boot.

So you could:

1. Delete the auto-created option pointing to LoadFile instance
2. Create your own one with customized description.





From: afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 10:47 AM
To:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>;
jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>
Cc: Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration







On Nov 5, 2019, at 7:34 PM, Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>> wrote:



Wouldn't having a variable that we create and delete on every boot put unnecessary stress on the SPI-NOR that the
variable store lives on?
What about the alternative approach where we allow the platform code to modify the attributes of the auto created
variable to disable it with hidden/!active but still match for detection purposes so that it doesn't delete and recreate the
modified variable each boot? That way all the logic on what to disable can still be in the platform code and all the existing
logic in the boot manager can stay basically the same?

What changes every boot that forces the variable to need to get modified?

I would assume the NOR driver is smart enough to not update a variable that is not changing.

The custom BDS could could only create the variable for this device if it does not exist.

[JB] The current flow with no changes in the boot manager would be as
follows



1. Scan for instance of the boot option in the variables
2. It will not be found, so create a new boot option store it to a variable and update BootOrder
3. Platform code runs creates the options for the boot option it wants and writes those to variable store
4. Delete/disable the boot option in the variable store



When you reboot it won't find the variable so 1/2/4 will re-occur



The code that does this (1/2) is EfiBootManagerRefreshAllBootOption in
BmBoot.c



If you modify the variable to disable it with hidden/not active it would delete that and create a new one as well as the
code wouldn't recognize that is the same boot option.



If however we modify EfiBootManagerFindLoadOption to not compare the attributes (at least allow for differences in
active and hidden) then the when it refreshes every thing it would see the match and not delete/create a new variable in
the store and thus we wouldn't have changes every boot.





Jeff,



Sorry if I'm a little off on the sequence of things as the platform I work on day to day has a custom BDS and does not use
this library..... I though the patch changed BmEnumerateBootOptions(), so that is going to change how
EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch as given is invalid as it changed the behavior of
the public library API for EfiBootManagerRefreshAllBootOption() [1] so for the patch to be valid it would need to change
the comments to reflect the new behavior. This is kind of what Laszlo's technical debt comment was about.



I think Laszlo advocated having the BDS platform specific code make sure the boot variables are in the correct state. That
should happen before the Boot Manager code runs, and it is not clear to me why the Boot Manager could would need to
run if you have a valid EFI nvram variable to boot from.



I think the question is how is your use case different than the boot variable that Windows installs? If it works kind of the
same way then the answer is to have the BDS platform specific code write the boot variable.





[1]

/**

The function creates boot options for all possible bootable medias in the following order:

1. Removable BlockIo - The boot option only points to the removable media

device, like USB key, DVD, Floppy etc.

2. Fixed BlockIo - The boot option only points to a Fixed blockIo device,

like HardDisk.

3. Non-BlockIo SimpleFileSystem - The boot option points to a device
supporting

SimpleFileSystem Protocol, but not
supporting BlockIo

protocol.

4. LoadFile - The boot option points to the media supporting

LoadFile protocol.

Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot
Behavior



The function won't delete the boot option not added by itself.

**/

VOID

EFIAPI

EfiBootManagerRefreshAllBootOption (

VOID

);



Thanks,



Andrew Fish



Thanks,

Andrew Fish

Thanks,

Jeff

________________________________

This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any
unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the
sender by reply email and destroy all copies of the original message.

________________________________





Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Wang, Sunny (HPS SW)
 

Sorry for the delay. Somehow I didn't catch the follow-up email. Thanks for checking my comments, Ray and Ashish.
Yeah, agree. 2.b is better. I will review the code change.

Regards,
Sunny Wang

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Ashish Singhal
Sent: Wednesday, December 18, 2019 4:16 AM
To: Jeff Brasen <jbrasen@nvidia.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration

I have submitted a patch based on 2.b as suggested by Ray. I am open to making changes in the structure of the protocol functions as well as the verbal description. Please let me know what you all think about it.

Thanks
Ashish
________________________________
From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Thursday, December 12, 2019 10:52 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Thanks for the summary Ray, for the problem summary only thing I would add would be that platform also wants to create/modify boot options when full enumeration is requested as well.

For solutions I prefer option 2 as we don't have to put the same logic everywhere of how to modify the default enumerated list. And if we do that 2b makes more sense as then we don't have to modify all of the existing platforms.

I see two things the platform would need to do.

1. Update list created in BmEnumerateBootOptions
2. Delete any no longer valid platform created boot options


Thanks,

Jeff

________________________________
From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, December 11, 2019 7:00 AM
To: Jeff Brasen <jbrasen@nvidia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

External email: Use caution opening links or attachments


Jeff,

Tom from AMD booked the meeting for SEV discussion months ago. I am afraid there is no time for this discussion.

Let's try to resolve it in mails.



Firstly, let me rephase the problem and your proposed solutions here (subjective + verb + objective). Sunny's input is also included. Hope Mike K and others can provide inputs.

Personally, I agree with 2.b. It helps us to gradually migrate the PlatformBootManagerLib to PlatformBootManager protocol. Protocol with Revision field helps to reduce the impact to old platforms with new APIs added.



**Problem:

Platform requires certain BlockIo/SimpleFileSystem/LoadFile instances don't cause Boot#### created. It's a need of platform customization.



**Details:

Boot#### for BlockIo/SimpleFileSystem/LoadFile are created by API EfiBootMangerRefreshAllBootOptions(). There are 2 places that call this API:

1. Platform Boot Manager calls the API (usually in the full configuration boot path)
2. UiApp calls the API when entering "Boot Manager" page and "Boot Maintenance Manager" page.



Platform can change Platform Boot Manager to remove the unneeded Boot#### in case #1.

But platform has no way to remove the Boot#### created in case #2 .



**Potential solutions:

1. Update UiApp
* Define a new PCD and a new event group.

If PCD is TRUE, UiApp signals the event. Event callback creates the Boot####. Otherwise, EfiBootManagerRefreshAllBootOptions() is called.

* Add a new PlatformBootManagerLib API (implemented by platform).

UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (need to coordinate rollout with updates to all platforms).

* Add a new protocol (implemented by platform).

UiApp calls the new protocol if it exists otherwise calls EfiBootManagerRefreshAllBootOption.



1. Update EfiBootManagerRefreshAllBootOptions()
* Add a new library class (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new library class.

* Add a new PlatformBootManager protocol (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists.



Thanks,

Ray



From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Can we discuss this at the design meeting this week (12/12)?



Thanks,

Jeff

________________________________

From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Yes, I think that would be good.



Summarizing everything in this thread



Problem: Platform needs to customize the boot options, this can be done for normal boot but the UiApp calls EfiBootManagerRefreshAllBootOption in a couple places.



Potential solutions:

1 - Define new PCD and event group if PCD is set true then signal event instead of calling EfiBootManagerRefreshAllBootOption in UiApp

2 - Add new function to boot manager library and replace call to EfiBootManagerRefreshAllBootOption in UiApp (need to coordinate rollout with updates to all platform.

3 - Add new protocol with new function, if supported call this otherwise call EfiBootManagerRefreshAllBootOption as is done now

4 - For 2/3 use generic function so we don't need new APIs for future expansion

5 - Update EfiBootManagerRefreshAllBootOption to call platform specific function.



Thanks,
Jeff





From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

I think it's a good topic that we could discuss in the open design meeting.

Are you ok to present the problem you have and discuss the potential solutions in that meeting?

https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Thursday, November 14, 2019 2:43 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Thinking about this more I think we could do this with a PCD and a new group event without having to define any new function interfaces.



We could change UiApp and BootManagerMenuApp (and any others that are relevant) from



EfiBootManagerRefreshAllBootOption ();



to



if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

EFI_EVENT Event;

gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid, &Event );

gBS->SignalEvent (Event);

gBS->CloseEvent (Event);

} else {

EfiBootManagerRefreshAllBootOption ();

}



Then a platform that wants to do this on its own would just set this pcd and create a group event and do what it needs to do there.



Thanks,

Jeff

________________________________

From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: Monday, November 11, 2019 5:00 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



I am not sure a PCD would work (unless I am missing something) We do want to do a connect all and re-enumerate in UiApp but we need the platform code to be involved in that process.



Thanks,

Jeff

________________________________

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Monday, November 11, 2019 4:58 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

If adding a PCD to control UiApp can meet the real needs, I prefer to do in that way instead of adding new APIs to PlatformBootManagerLib.



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Tuesday, November 12, 2019 6:58 AM
To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



If we are concerned about deploying this and breaking builds we could do this via a new protocol instead. In that case though we would leave the old default behavior in the code to handle platforms that didn't implement the new protocol, so this might not be the cleanest way to deploy this.



We could also look at adding a generic platform boot hook function (either as a library function or protocol) if we wanted to limit the number of disruption on new customization hooks. Something like



EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *ContextData OPTIONAL)



Where Notification type describes where we are that we want platform to potentially handle and ContextData is per type caller allocated data that provides additional in/out data. This has the same issue of leaving the current default behavior in place for unsupported types as well as being a less than specific function to describe.



Thanks,

Jeff



________________________________

From: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
Sent: Friday, November 8, 2019 9:37 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



On 11/07/19 18:46, Jeff Brasen wrote:
Fixing UiApp seems reasonable, I do think we would want a hook to the platform library in here as the enumeration that occurs in the UiApp is intended to do a full enumeration of the system and there may be platform specifics to how that occurs.
Fully agreed -- entering UiApp should expose everything bootable in the system, unless (perhaps) PlatformBootManagerLib specifically thinks otherwise.

Of course, then we arrive (again) at the problem that a call in UefiBootManagerLib, to a *new* PlatformBootManagerLib API, will break tens of out-of-tree platforms. :)

I think that can be prevented, as follows; but it will take quite some time:

- introduce the new function declaration in "PlatformBootManagerLib.h",
- modify all platforms (in tree and out of tree) to implement (define) the new function,
- call the new function from UefiBootManagerLib

For some history / background on this kind of problem, I suggest reading
through:

https://bugzilla.tianocore.org/show_bug.cgi?id=982

Thanks,
Laszlo

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Thursday, November 7, 2019 12:21 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>;
afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Laszlo
Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael
D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration

I treat the issue in this way:

1. Platform Boot Manager library does a good job. It doesn't always call RefreshAll() API to auto-create the boot options
2. But UiApp doesn't. It constantly call RefreshAll().

Do you think that we can fix UiApp instead? For example, introducing a PCD to control the boot option refresh behavior?

Thanks,
Ray

From:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gr
oups.io%3cmailto:devel@edk2.groups.io>>> On Behalf Of Jeff Brasen
Sent: Thursday, November 7, 2019 3:02 PM
To: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>; afish@apple.com<mailto:afish@apple.com>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration

The issue is there are some auto created options we do not want on our platform.
Get Outlook for
Android<INVALID URI REMOVED
ei36&d=DwIF-g&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJ
UR24f8N3205AYw&m=EzQH7xR5u0kejdb3Oa18jqGGrV5AO_ROvd_Y_ajQQMk&s=yaH1ZcO
LL9iVBCGMBGKtuwgPVbblPxtJooJMnpxn8P0&e= >

________________________________
From: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Sent: Wednesday, November 6, 2019 11:59:31 PM
To: Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>;
afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>
<devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gr
oups.io%3cmailto:devel@edk2.groups.io>>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration


Jeff,

RefreshAllBootOption() only modifies/creates the auto-created boot options. For the boot options created by platform boot manager library, they stay with no one touches. And all auto-created boot options are appended in the end of boot option list (through BootOrder).



From: Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>
Sent: Thursday, November 7, 2019 12:13 PM
To: afish@apple.com<mailto:afish@apple.com>; Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration



As the suggestions below made sense, we updated our platform boot manager library to behave in this manner and for normal boots everything works well. However the UiApp and boot maintenance applications in EDK2 also call EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu which will re-create the skipped boot options with no place for the platform code to intervene.



What about a solution where we add a new Platform library function that allows for override of the behavior of BmEnumerateBootOptions? For example, either a function or protocol that takes the same parameters as this function and only if it returns NULL then we continue to the default enumeration code. Or a function call inserted at the end that would modify the load option array after the system does the standard enumeration.



-Jeff



From: afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 9:20 AM
To: Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>
Cc:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>; Jeff Brasen
<jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.co
m%3cmailto:jbrasen@nvidia.com>>>; Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Mike Kinney
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration



Ray,



Is there an obvious hook point we could point Jeff and Ashish at?



Long term it would be a good idea to have a Wiki page to give some guidance on how to customize the BDS.



Thanks,



Andrew Fish



On Nov 5, 2019, at 9:20 PM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>> wrote:



Andrew,

I agree with your opinion.

It's expected that Platform Boot Manager lib calls EfiBootManagerRefreshAllBootOption() only in full configuration boot path.

The full configuration boot path is chosen when hardware changes
happen. So it's not expected EfiBootManagerRefresh...() be called in every boot.

So you could:

1. Delete the auto-created option pointing to LoadFile instance
2. Create your own one with customized description.





From: afish@apple.com<mailto:afish@apple.com>
<afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailt
o:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 10:47 AM
To:
devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.gro
ups.io%3cmailto:devel@edk2.groups.io>>;
jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>
Cc: Ashish Singhal
<ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishs
ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek
<lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3
cmailto:lersek@redhat.com>>>; Ni, Ray
<ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cma
ilto:ray.ni@intel.com>>>; Wang, Jian J
<jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang
@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A
<hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.co
m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao
<zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao
@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D
<michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:m
ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM
enumeration







On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>> wrote:



Wouldn't having a variable that we create and delete on every boot put unnecessary stress on the SPI-NOR that the variable store lives on?
What about the alternative approach where we allow the platform code to modify the attributes of the auto created variable to disable it with hidden/!active but still match for detection purposes so that it doesn't delete and recreate the modified variable each boot? That way all the logic on what to disable can still be in the platform code and all the existing logic in the boot manager can stay basically the same?

What changes every boot that forces the variable to need to get modified?

I would assume the NOR driver is smart enough to not update a variable that is not changing.

The custom BDS could could only create the variable for this device if it does not exist.

[JB] The current flow with no changes in the boot manager would be as
follows



1. Scan for instance of the boot option in the variables
2. It will not be found, so create a new boot option store it to a variable and update BootOrder
3. Platform code runs creates the options for the boot option it wants and writes those to variable store
4. Delete/disable the boot option in the variable store



When you reboot it won't find the variable so 1/2/4 will re-occur



The code that does this (1/2) is EfiBootManagerRefreshAllBootOption in
BmBoot.c



If you modify the variable to disable it with hidden/not active it would delete that and create a new one as well as the code wouldn't recognize that is the same boot option.



If however we modify EfiBootManagerFindLoadOption to not compare the attributes (at least allow for differences in active and hidden) then the when it refreshes every thing it would see the match and not delete/create a new variable in the store and thus we wouldn't have changes every boot.





Jeff,



Sorry if I'm a little off on the sequence of things as the platform I work on day to day has a custom BDS and does not use this library..... I though the patch changed BmEnumerateBootOptions(), so that is going to change how EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch as given is invalid as it changed the behavior of the public library API for EfiBootManagerRefreshAllBootOption() [1] so for the patch to be valid it would need to change the comments to reflect the new behavior. This is kind of what Laszlo's technical debt comment was about.



I think Laszlo advocated having the BDS platform specific code make sure the boot variables are in the correct state. That should happen before the Boot Manager code runs, and it is not clear to me why the Boot Manager could would need to run if you have a valid EFI nvram variable to boot from.



I think the question is how is your use case different than the boot variable that Windows installs? If it works kind of the same way then the answer is to have the BDS platform specific code write the boot variable.





[1]

/**

The function creates boot options for all possible bootable medias in the following order:

1. Removable BlockIo - The boot option only points to the removable media

device, like USB key, DVD, Floppy etc.

2. Fixed BlockIo - The boot option only points to a Fixed blockIo device,

like HardDisk.

3. Non-BlockIo SimpleFileSystem - The boot option points to a device
supporting

SimpleFileSystem Protocol, but not
supporting BlockIo

protocol.

4. LoadFile - The boot option points to the media supporting

LoadFile protocol.

Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot
Behavior



The function won't delete the boot option not added by itself.

**/

VOID

EFIAPI

EfiBootManagerRefreshAllBootOption (

VOID

);



Thanks,



Andrew Fish



Thanks,

Andrew Fish

Thanks,

Jeff

________________________________

This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

________________________________


Re: Does EmulatorPkg support source-level debug?

Yeh
 

Hi Liming,

Thanks for the information.
But may I know how to do that in VS?

Is it possible to build the EDK2 by the VS?
Now I am building it by the Windows command line.


Re: Lock BootOrder variable

Sean
 

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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; Sean Brogan <sean.brogan@microsoft.com>; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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&amp;sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&amp;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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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&amp;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: 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&amp;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.

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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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&amp;sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&amp;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




Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Ashish Singhal
 

I have submitted a patch based on 2.b as suggested by Ray. I am open to making changes in the structure of the protocol functions as well as the verbal description. Please let me know what you all think about it.

Thanks
Ashish
________________________________
From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Thursday, December 12, 2019 10:52 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Thanks for the summary Ray, for the problem summary only thing I would add would be that platform also wants to create/modify boot options when full enumeration is requested as well.

For solutions I prefer option 2 as we don't have to put the same logic everywhere of how to modify the default enumerated list. And if we do that 2b makes more sense as then we don't have to modify all of the existing platforms.

I see two things the platform would need to do.

1. Update list created in BmEnumerateBootOptions
2. Delete any no longer valid platform created boot options


Thanks,

Jeff

________________________________
From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, December 11, 2019 7:00 AM
To: Jeff Brasen <jbrasen@nvidia.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@apple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

External email: Use caution opening links or attachments


Jeff,

Tom from AMD booked the meeting for SEV discussion months ago. I am afraid there is no time for this discussion.

Let’s try to resolve it in mails.



Firstly, let me rephase the problem and your proposed solutions here (subjective + verb + objective). Sunny’s input is also included. Hope Mike K and others can provide inputs.

Personally, I agree with 2.b. It helps us to gradually migrate the PlatformBootManagerLib to PlatformBootManager protocol. Protocol with Revision field helps to reduce the impact to old platforms with new APIs added.



**Problem:

Platform requires certain BlockIo/SimpleFileSystem/LoadFile instances don’t cause Boot#### created. It’s a need of platform customization.



**Details:

Boot#### for BlockIo/SimpleFileSystem/LoadFile are created by API EfiBootMangerRefreshAllBootOptions(). There are 2 places that call this API:

1. Platform Boot Manager calls the API (usually in the full configuration boot path)
2. UiApp calls the API when entering “Boot Manager” page and “Boot Maintenance Manager” page.



Platform can change Platform Boot Manager to remove the unneeded Boot#### in case #1.

But platform has no way to remove the Boot#### created in case #2 .



**Potential solutions:

1. Update UiApp
* Define a new PCD and a new event group.

If PCD is TRUE, UiApp signals the event. Event callback creates the Boot####. Otherwise, EfiBootManagerRefreshAllBootOptions() is called.

* Add a new PlatformBootManagerLib API (implemented by platform).

UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (need to coordinate rollout with updates to all platforms).

* Add a new protocol (implemented by platform).

UiApp calls the new protocol if it exists otherwise calls EfiBootManagerRefreshAllBootOption.



1. Update EfiBootManagerRefreshAllBootOptions()
* Add a new library class (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new library class.

* Add a new PlatformBootManager protocol (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists.



Thanks,

Ray



From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Can we discuss this at the design meeting this week (12/12)?



Thanks,

Jeff

________________________________

From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Yes, I think that would be good.



Summarizing everything in this thread



Problem: Platform needs to customize the boot options, this can be done for normal boot but the UiApp calls EfiBootManagerRefreshAllBootOption in a couple places.



Potential solutions:

1 – Define new PCD and event group if PCD is set true then signal event instead of calling EfiBootManagerRefreshAllBootOption in UiApp

2 – Add new function to boot manager library and replace call to EfiBootManagerRefreshAllBootOption in UiApp (need to coordinate rollout with updates to all platform.

3 – Add new protocol with new function, if supported call this otherwise call EfiBootManagerRefreshAllBootOption as is done now

4 – For 2/3 use generic function so we don’t need new APIs for future expansion

5 – Update EfiBootManagerRefreshAllBootOption to call platform specific function.



Thanks,
Jeff





From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

I think it’s a good topic that we could discuss in the open design meeting.

Are you ok to present the problem you have and discuss the potential solutions in that meeting?

https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Thursday, November 14, 2019 2:43 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Thinking about this more I think we could do this with a PCD and a new group event without having to define any new function interfaces.



We could change UiApp and BootManagerMenuApp (and any others that are relevant) from



EfiBootManagerRefreshAllBootOption ();



to



if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

EFI_EVENT Event;

gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid, &Event );

gBS->SignalEvent (Event);

gBS->CloseEvent (Event);

} else {

EfiBootManagerRefreshAllBootOption ();

}



Then a platform that wants to do this on its own would just set this pcd and create a group event and do what it needs to do there.



Thanks,

Jeff

________________________________

From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>
Sent: Monday, November 11, 2019 5:00 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



I am not sure a PCD would work (unless I am missing something) We do want to do a connect all and re-enumerate in UiApp but we need the platform code to be involved in that process.



Thanks,

Jeff

________________________________

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Monday, November 11, 2019 4:58 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

If adding a PCD to control UiApp can meet the real needs, I prefer to do in that way instead of adding new APIs to PlatformBootManagerLib.



Thanks,

Ray



From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Tuesday, November 12, 2019 6:58 AM
To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



If we are concerned about deploying this and breaking builds we could do this via a new protocol instead. In that case though we would leave the old default behavior in the code to handle platforms that didn't implement the new protocol, so this might not be the cleanest way to deploy this.



We could also look at adding a generic platform boot hook function (either as a library function or protocol) if we wanted to limit the number of disruption on new customization hooks. Something like



EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *ContextData OPTIONAL)



Where Notification type describes where we are that we want platform to potentially handle and ContextData is per type caller allocated data that provides additional in/out data. This has the same issue of leaving the current default behavior in place for unsupported types as well as being a less than specific function to describe.



Thanks,

Jeff



________________________________

From: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
Sent: Friday, November 8, 2019 9:37 AM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



On 11/07/19 18:46, Jeff Brasen wrote:
Fixing UiApp seems reasonable, I do think we would want a hook to the platform library in here as the enumeration that occurs in the UiApp is intended to do a full enumeration of the system and there may be platform specifics to how that occurs.
Fully agreed -- entering UiApp should expose everything bootable in the
system, unless (perhaps) PlatformBootManagerLib specifically thinks
otherwise.

Of course, then we arrive (again) at the problem that a call in
UefiBootManagerLib, to a *new* PlatformBootManagerLib API, will break
tens of out-of-tree platforms. :)

I think that can be prevented, as follows; but it will take quite some time:

- introduce the new function declaration in "PlatformBootManagerLib.h",
- modify all platforms (in tree and out of tree) to implement (define)
the new function,
- call the new function from UefiBootManagerLib

For some history / background on this kind of problem, I suggest reading
through:

https://bugzilla.tianocore.org/show_bug.cgi?id=982

Thanks,
Laszlo

From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Sent: Thursday, November 7, 2019 12:21 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>; afish@apple.com<mailto:afish@apple.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

I treat the issue in this way:

1. Platform Boot Manager library does a good job. It doesn't always call RefreshAll() API to auto-create the boot options
2. But UiApp doesn't. It constantly call RefreshAll().

Do you think that we can fix UiApp instead? For example, introducing a PCD to control the boot option refresh behavior?

Thanks,
Ray

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>> <devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>> On Behalf Of Jeff Brasen
Sent: Thursday, November 7, 2019 3:02 PM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>>; afish@apple.com<mailto:afish@apple.com>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3cmailto:lersek@redhat.com>>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.com%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

The issue is there are some auto created options we do not want on our platform.
Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>>
Sent: Wednesday, November 6, 2019 11:59:31 PM
To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>>; afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailto:afish@apple.com>>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>> <devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3cmailto:lersek@redhat.com>>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.com%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration


Jeff,

RefreshAllBootOption() only modifies/creates the auto-created boot options. For the boot options created by platform boot manager library, they stay with no one touches. And all auto-created boot options are appended in the end of boot option list (through BootOrder).



From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>>
Sent: Thursday, November 7, 2019 12:13 PM
To: afish@apple.com<mailto:afish@apple.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3cmailto:lersek@redhat.com>>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.com%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



As the suggestions below made sense, we updated our platform boot manager library to behave in this manner and for normal boots everything works well. However the UiApp and boot maintenance applications in EDK2 also call EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu which will re-create the skipped boot options with no place for the platform code to intervene.



What about a solution where we add a new Platform library function that allows for override of the behavior of BmEnumerateBootOptions? For example, either a function or protocol that takes the same parameters as this function and only if it returns NULL then we continue to the default enumeration code. Or a function call inserted at the end that would modify the load option array after the system does the standard enumeration.



-Jeff



From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailto:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 9:20 AM
To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>; Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3cmailto:lersek@redhat.com>>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.com%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao@intel.com%3cmailto:zhichao.gao@intel.com>>>; Mike Kinney <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Ray,



Is there an obvious hook point we could point Jeff and Ashish at?



Long term it would be a good idea to have a Wiki page to give some guidance on how to customize the BDS.



Thanks,



Andrew Fish



On Nov 5, 2019, at 9:20 PM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>> wrote:



Andrew,

I agree with your opinion.

It's expected that Platform Boot Manager lib calls EfiBootManagerRefreshAllBootOption() only in full configuration boot path.

The full configuration boot path is chosen when hardware changes happen. So it's not expected EfiBootManagerRefresh...() be
called in every boot.

So you could:

1. Delete the auto-created option pointing to LoadFile instance
2. Create your own one with customized description.





From: afish@apple.com<mailto:afish@apple.com> <afish@apple.com<mailto:afish@apple.com<mailto:afish@apple.com%3cmailto:afish@apple.com>>>
Sent: Wednesday, November 6, 2019 10:47 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>; jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com<mailto:lersek@redhat.com%3cmailto:lersek@redhat.com>>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com<mailto:ray.ni@intel.com%3cmailto:ray.ni@intel.com>>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com<mailto:hao.a.wu@intel.com%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com<mailto:zhichao.gao@intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration







On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com<mailto:jbrasen@nvidia.com%3cmailto:jbrasen@nvidia.com>>> wrote:



Wouldn't having a variable that we create and delete on every boot put unnecessary stress on the SPI-NOR that the variable store lives on?
What about the alternative approach where we allow the platform code to modify the attributes of the auto created variable to disable it with hidden/!active but still match for detection purposes so that it doesn't delete and recreate the modified variable each boot? That way all the logic on what to disable can still be in the platform code and all the existing logic in the boot manager can stay basically the same?

What changes every boot that forces the variable to need to get modified?

I would assume the NOR driver is smart enough to not update a variable that is not changing.

The custom BDS could could only create the variable for this device if it does not exist.

[JB] The current flow with no changes in the boot manager would be as follows



1. Scan for instance of the boot option in the variables
2. It will not be found, so create a new boot option store it to a variable and update BootOrder
3. Platform code runs creates the options for the boot option it wants and writes those to variable store
4. Delete/disable the boot option in the variable store



When you reboot it won't find the variable so 1/2/4 will re-occur



The code that does this (1/2) is EfiBootManagerRefreshAllBootOption in BmBoot.c



If you modify the variable to disable it with hidden/not active it would delete that and create a new one as well as the code wouldn't recognize that is the same boot option.



If however we modify EfiBootManagerFindLoadOption to not compare the attributes (at least allow for differences in active and hidden) then the when it refreshes every thing it would see the match and not delete/create a new variable in the store and thus we wouldn't have changes every boot.





Jeff,



Sorry if I'm a little off on the sequence of things as the platform I work on day to day has a custom BDS and does not use this library..... I though the patch changed BmEnumerateBootOptions(), so that is going to change how EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch as given is invalid as it changed the behavior of the public library API for EfiBootManagerRefreshAllBootOption() [1] so for the patch to be valid it would need to change the comments to reflect the new behavior. This is kind of what Laszlo's technical debt comment was about.



I think Laszlo advocated having the BDS platform specific code make sure the boot variables are in the correct state. That should happen before the Boot Manager code runs, and it is not clear to me why the Boot Manager could would need to run if you have a valid EFI nvram variable to boot from.



I think the question is how is your use case different than the boot variable that Windows installs? If it works kind of the same way then the answer is to have the BDS platform specific code write the boot variable.





[1]

/**

The function creates boot options for all possible bootable medias in the following order:

1. Removable BlockIo - The boot option only points to the removable media

device, like USB key, DVD, Floppy etc.

2. Fixed BlockIo - The boot option only points to a Fixed blockIo device,

like HardDisk.

3. Non-BlockIo SimpleFileSystem - The boot option points to a device supporting

SimpleFileSystem Protocol, but not supporting BlockIo

protocol.

4. LoadFile - The boot option points to the media supporting

LoadFile protocol.

Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot Behavior



The function won't delete the boot option not added by itself.

**/

VOID

EFIAPI

EfiBootManagerRefreshAllBootOption (

VOID

);



Thanks,



Andrew Fish



Thanks,

Andrew Fish

Thanks,

Jeff

________________________________

This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

________________________________


Re: Lock BootOrder variable

Tim Lewis
 

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@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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,

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




Re: Does EmulatorPkg support source-level debug?

Liming Gao
 

Yes. You can use VS do source level debug. Please see https://edk2.groups.io/g/devel/message/49972

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Yeh
Sent: Tuesday, December 17, 2019 4:25 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Does EmulatorPkg support source-level debug?

HI,

I am wondering if EmulatorPkg supports source-level debug on VS2017 build.
Can I know if there is any documentation for that?

Thanks,
Yeh


Does EmulatorPkg support source-level debug?

Yeh
 

HI,

I am wondering if EmulatorPkg supports source-level debug on VS2017 build.
Can I know if there is any documentation for that?

Thanks,
Yeh


Re: Lock BootOrder variable

Wang, Sunny (HPS SW)
 

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@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
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@riseup.net; sunnywang@hpe.com
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@hpe.com
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@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
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,

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



781 - 800 of 885