|
EFI Group Event Callback Order
Li, Walon <walon.li@...>
Hi edk2,  As UEFI event group mechanism, we can register callbacks under event group. For example, register two event callbacks and will be signal in ReadyToBoot.  Status = gBS->CreateEventEx (                  EVT_NOTIFY_SIGNAL,                  TPL_CALLBACK,                  TestCallback1,                  NULL,                  &gEfiEventReadyToBootGuid,                  &ReadyToBootEvent                  );  Status = gBS->CreateEventEx (                  EVT_NOTIFY_SIGNAL,                  TPL_CALLBACK,                  TestCallback2,                  NULL,                  &gEfiEventReadyToBootGuid,                  &ReadyToBootEvent                  ); I'm curious the order of callback. In this case, the order is LIFO and TestCallback2 will be executed than TestCallback1. As the UEFI spec page 152, only said "If the supplied Event is a part of an event group, then all of the events in the event group are also signaled and their notification functions are scheduled." It doesn't define order clearly.  However, edk2 has different implementation in EVT_RUNTIME / EVT_NOTIFY_SIGNAL attribute of group event. In Event.c, it inserts new event to Head in EVT_NOTIFY_SIGNAL queue (LIFO) and inserts to Tail in EVT_RUNTIME queue (FIFO). I know the programmer shouldn't assume any order but want to know why is different implementation in group event. Have any history reason or limitation?   if ((Type & EVT_RUNTIME) != 0) {    //    // Keep a list of all RT events so we can tell the RT AP.    //    IEvent->RuntimeData.Type          = Type;    IEvent->RuntimeData.NotifyTpl     = NotifyTpl;    IEvent->RuntimeData.NotifyFunction = NotifyFunction;    IEvent->RuntimeData.NotifyContext = (VOID *) NotifyContext;    //    // Work around the bug in the Platform Init specification (v1.7), reported    // as Mantis#2017: "EFI_RUNTIME_EVENT_ENTRY.Event" should have type    // EFI_EVENT, not (EFI_EVENT*). The PI spec documents the field correctly    // as "The EFI_EVENT returned by CreateEvent()", but the type of the field    // doesn't match the natural language description. Therefore we need an    // explicit cast here.    //    IEvent->RuntimeData.Event         = (EFI_EVENT *) IEvent;    InsertTailList (&gRuntime->EventHead, &IEvent->RuntimeData.Link);  }   CoreAcquireEventLock ();   if ((Type & EVT_NOTIFY_SIGNAL) != 0x00000000) {    //    // The Event's NotifyFunction must be queued whenever the event is signaled    //    InsertHeadList (&gEventSignalQueue, &IEvent->SignalLink);  }  Thank you, Walon
|
|
|
|
Re: Analogous to Print() but for keyboard input?
Laszlo Ersek
On 01/13/20 05:34, alejandro.estay@gmail.com wrote:
Is there some library like UefiLib, with some function working likeI don't really understand your question. If you are looking for functions that parse string representations of integers into integer variables, "MdePkg/Include/Library/BaseLib.h" has: (Ascii)?Str(Decimal|Hex)ToUint(64|n)S? Before exposing any such function to untrusted input, I'd strongly recommend double-checking the implementation. For regular expressions, you could include RegularExpressionDxe in your platform build, and use EFI_REGULAR_EXPRESSION_PROTOCOL. HTH Laszlo
|
|
|
|
Re: Is possible to obtain assembly output from modules?
Laszlo Ersek
On 01/14/20 04:41, alejandro.estay@gmail.com wrote:
HiThe way I generally do this (for OVMF) is as follows: - run a complete NOOPT build - run a command like: objdump -S Build/Ovmf3264/NOOPT_GCC48/X64/MdeModulePkg/Core/PiSmmCore/PiSmmCore/DEBUG/PiSmmCore.debug \ | less This is going to give you a disassembly intermixed with C source code, for the "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c" file. Update the pathname as necessary. Thanks Laszlo
|
|
|
|
Is possible to obtain assembly output from modules?
alejandro.estay@...
Hi
I want to check some .efi and call format stuff. However I don't know exactly how to produce assembly output from edk2 gcc. I was trying to tweak .dsc. The problem is that the last file is compile overwrites the rrest for every module. I pasted this at the end of MdeModulePkg last line -Wa,-adhln=asmdump.asm However asmdump.asm only contains listing for the last file compiled in the module Is there a better way to do this?
|
|
|
|
Analogous to Print() but for keyboard input?
alejandro.estay@...
HI
Is there some library like UefiLib, with some function working like scanf()? For example, print() shares some things with printf(), but I can't find any related to input working that way. Really appreciate your comments Thanks
|
|
|
|
Re: Lock BootOrder variable
Laszlo Ersek
On 01/03/20 18:48, Laszlo Ersek wrote:
Furthermore, we already have RuntimeServicesSupported, for exposingJust because I mentioned RuntimeServicesSupported, I guess it makes sense to reference this spec ticket too: https://mantis.uefi.org/mantis/view.php?id=2049 Thanks Laszlo
|
|
|
|
Re: Lock BootOrder variable
Laszlo Ersek
On 12/18/19 11:03, Wang, Sunny (HPS SW) wrote:
Hi Sean,Locking the boot order by way of causing SetVariable to fail for the OS seems wrong to me. BDS is platform policy. A platform BDS implementation can simply re-generate all Boot#### variables, and the BootOrder variable, from scratch, every time the platform boots. Why is that not sufficient? (For example, platform BDS could base that boot order re-generation on a set of boot-time only variables.) Furthermore, we already have RuntimeServicesSupported, for exposing (among other things) that SetVariable doesn't work, "en bloc". Punching further holes into previously promised interfaces, piece-meal, is becoming quite baroque. I don't understand how "security" is improved by locking down boot order. We already have Secure Boot for executing trusted binaries only, and we already have TCG2 / TPM2 for tying secrets to any and all aspects of the boot path (such as executables launched, the order they are launched in, their config files, and so on). Anyway, I've CC'd Javier and Peter from the rhboot team. Laszlo -----Original Message-----
|
|
|
|
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)(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);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
|
|
|
|
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 -mSourceLevelDebugPkg/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.efiThis 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. :)
toggle quoted messageShow quoted text
-----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,
|
|
|
|
Re: Does EmulatorPkg support source-level debug?
Yeh
I have found out how to debug on the VS.
https://docs.microsoft.com/zh-tw/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019 Thank you.
|
|
|
|
Re: Lock BootOrder variable
Tim Lewis
Sunny --
toggle quoted messageShow quoted text
Thanks for the clarification. Tim
-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Wang, Sunny (HPS SW) Sent: Wednesday, December 18, 2019 1:45 AM To: tim.lewis@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,
|
|
|
|
Re: Does EmulatorPkg support source-level debug?
Liming Gao
I build and run Emulator with below command.
toggle quoted messageShow quoted text
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-----
|
|
|
|
Re: Lock BootOrder variable
Wang, Sunny (HPS SW)
Hi Sean,
toggle quoted messageShow quoted text
Thanks for checking this further and bringing this to the Microsoft OS team. Yeah, your guess is part of the solution that I'm working on. I'm making a spec'd way to fix this and will bring it to USWG and EDK2 design meeting to further discuss with you guys. Moreover, I tried RHEL and SLES as well, and ran into the same problem (installation failure). Therefore, it will be good if some people from Linux OS vendors in this email list can also help drive this for Linux OS. Of course, I will still bring this to USWG for checking if we need to add a description into UEFI specification for asking/reminding OS to gracefully deal with the locked variable (and error status from the runtime variable service). Regards, Sunny Wang
-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Sean via Groups.Io Sent: Wednesday, December 18, 2019 4:55 AM To: Wang, Sunny (HPS SW) <sunnywang@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&sdata=xjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ%3D&reserved=0 However, It looks like we would still run into the OS installation failure with the current VariablePolicy protocol implementation. I didn't deeply look into the VariablePolicy protocol or give it a try, so I may overlook the solution in your implementation. Could you help point out where the code for solving OS installation failure is? The problem here is that OS doesn't gracefully deal with the locked UEFI variable, so we may not be able to return EFI_WRITE_PROTECTED to OS for the writes to BootOrder. Hi All, I think we all agree with the following points: 1. There is a need to lock BootOrder like the information brought by Samer and NIST 800-193 guidelines. 2. OS needs to gracefully deal with the locked BootOrder without causing failure during the installation and operations. 3. We will at least need to update the UEFI specification for asking OS to gracefully deal with the locked variable. If no one is currently working on this, I will bring it to USWG and work on it. Regards, Sunny Wang -----Original Message----- From: tim.lewis@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&sdata=avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg%3D&reserved=0 A relatively limited solution with hard coded lock points tied to edk2 SMM variable store. 2. Project Mu VariablePolicy protocol: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fblob%2Frelease%2F201911%2FMdeModulePkg%2FInclude%2FProtocol%2FVariablePolicy.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&sdata=14Wv%2B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c%3D&reserved=0 Flexible policy based locking that can be implemented in various hardware architectures. My team will be proposing the VariablePolicy protocol (potentially as a "code-first" effort) in the coming months and working to upstream this feature into edk2. The reality is some users and use cases want higher assurance for their platform settings and this can include the boot order. Doing this thru a well-defined and auditable protocol is better than an ad-hoc solutions. As you know locking some variables may break assumptions (or spec definition) that other code may have but that tradeoff is best evaluated by the use case. Thanks Sean -----Original Message----- From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Paulo Henrique Lacerda de Amorim via Groups.Io Sent: Thursday, December 12, 2019 12:53 PM To: discuss@edk2.groups.io; sunnywang@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&sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&reserved=0= . Thanks, Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu: Hi All,
|
|
|
|
Re: Lock BootOrder variable
Wang, Sunny (HPS SW)
Hi Tim,
toggle quoted messageShow quoted text
You can check the section 2.2.2.1 Critical Data. The Boot order is identified as critical data that should be protected. Yes, we can see this case on server platforms (enterprise solution and service provider) Regards, Sunny Wang
-----Original Message-----
From: tim.lewis@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,
|
|
|
|
Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration
Ni, Ray
Sunny,
toggle quoted messageShow quoted text
Thanks for your comments. Thanks, Ray
-----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.
toggle quoted messageShow quoted text
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>>
|
|
|
|
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.
|
|
|