Date   

Re: HTTP boot failed on timeout

Laszlo Ersek
 

On 02/17/20 11:52, doron.bleiberg@ecitele.com wrote:
Hi Laszlo,

Thank you for the quick and detailed response. Some answers to your questions:
- Since I'm running the VMs as part of GNS3 project I'm not having full control over the VM startup command. I will try to run the VM outside GNS3 context just to make sure I'm having cleaner and more controlled environment.
- I'm using qcow2 drive file which is the HDD on which the net installation should run. The drive is empty waiting for the installation after boot completion.


I've used your suggestion for adding a 'romfile=""' property. I did it this way as I can't edit the device properties (GNS3...):
-global virtio-net-pci.romfile=""

Can you explain what is the meaning of setting this property and why it is related to my problem?
It is not necessarily related to your problem; it *could* be related.

The romfile property tells QEMU what PCI expansion ROM to load into the
device's PCI option ROM BAR. By default the ROM in question is built
from the iPXE project. This means that the Simple Network Protocol
driver that talks to the virtio-net-pci device directly in OVMF comes
from the iPXE project.

OVMF has a built-in driver (VirtioNetDxe) for the same device however,
it just has lower priority. So if you want VirtioNetDxe to take control
of the device, you need to prevent the loading of the expansion ROM
described above. That's what romfile='' does.

And this could be relevant to your problem because the SNP driver lies
at the bottom of the edk2 network stack (in OVMF anyway). If there is a
problem in your iPXE SNP driver, then that could affect the dependent
TCP connection, and hang your HTTP boot. Switching in the VirtioNetDxe
driver might show a difference here.

Note: I'm not blindly blaming the iPXE driver; I'm just saying it
*could* be related. Seeing how your QEMU binary is ancient (4+ years
old), there could be old iPXE issues affecting your iPXE expansion ROM
too, that have been fixed since, up-stream.

Also, if not suggested to use -bios what are the alternatives?
You should use the split build of OVMF (OVMF_CODE.fd and OVMF_VARS.fd).
OVMF_CODE.fd is the firmware executable. OVMF_VARS.fd is a *template*
file for creating actual variable store files from, when defining a new
domain. Once you define a new domain, the varstore file that was
originally copied from OVMF_VARS.fd should be considered basically
another "data disk" for the domain. The varstore file is where
persistent (non-volatile) UEFI variables are stored, for the domain.

With "-bios", you get a varstore emulation that's not spec-conformant.
It suffers from various obscure problems. Don't use it.

The related (traditional) QEMU cmdline options are shown below. There is
a more recent, more modern, format for the same, but that format
requires a newer QEMU release. (For details, check out
<http://mid.mail-archive.com/146b553d-cbe7-ac87-9423-bd07602e3e01@redhat.com>.
But honestly, the best idea is to just use libvirt.)

So, the original options are:

-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=guest-vars.fd \

where "guest-vars.fd" is specific to the guest in question, and was
originally copied from OVMF_VARS.fd.

If your distro doesn't package OVMF_CODE.fd and OVMF_VARS.fd separately,
then it's too old.

Is there an option for me to also skip 'Start PXE over IPv4' part from happening in the boot process?
No, there's not. While you can influence the UEFI boot order from the
QEMU command line, for example with:

-device virtio-net-pci,[other options],bootindex=0

the QEMU <-> firmware interface that exposes this to the firmware --
specifically, the "bootorder" fw_cfg file -- is not expressive enough to
tell apart PXE boot on a given NIC from HTTPv4 boot on the same NIC. You
can specify a particular NIC, but given that NIC, you'll have to stick
with the edk2-default boot order for a NIC.

If you can go into the firmware setup TUI once, and manually reorder the
PXE vs. HTTPv4 boot options, then OVMF will generally stick with that
order for you (until / unless you instruct OVMF to drop netboot from the
boot order altogether). But that requires you to interact with the guest
firmware.


This suggestion worked well! and I was able to fully download the file. Thank you!
Oh wow. :) So, it *is* related to the iPXE SNP driver.

For reference, can you search your installed package set for packages
that have "ipxe" in the name? Can you list their names and versions?

Basically now I expect that you are using your distro's very outdated
iPXE package, whose issues have long been fixed up-stream.

The only problem now, is that I get kernel panic on the next step - who said life are simple..... ;-)

I'll continue to debug the kernel panic.

I've attached qemu.log just in case.
Thanks,
Laszlo


Re: HTTP boot failed on timeout

doron.bleiberg@...
 

Hi Laszlo,

Thank you for the quick and detailed response. Some answers to your questions:
- Since I'm running the VMs as part of GNS3 project I'm not having full control over the VM startup command. I will try to run the VM outside GNS3 context just to make sure I'm having cleaner and more controlled environment.
- I'm using qcow2 drive file which is the HDD on which the net installation should run. The drive is empty waiting for the installation after boot completion.


I've used your suggestion for adding a 'romfile=""' property. I did it this way as I can't edit the device properties (GNS3...):
-global virtio-net-pci.romfile=""

Can you explain what is the meaning of setting this property and why it is related to my problem?
Also, if not suggested to use -bios what are the alternatives?
Is there an option for me to also skip 'Start PXE over IPv4' part from happening in the boot process?

This suggestion worked well! and I was able to fully download the file. Thank you!
The only problem now, is that I get kernel panic on the next step - who said life are simple..... ;-)

I'll continue to debug the kernel panic.

I've attached qemu.log just in case.

Doron


Re: HTTP boot failed on timeout

Laszlo Ersek
 

On 02/17/20 10:45, doron.bleiberg@ecitele.com wrote:
Some inputs:
Qemu version: QEMU emulator version 2.5.0 (Debian
1:2.5+dfsg-5ubuntu10.34), Copyright (c) 2003-2008 Fabrice Bellard
Qemu CMD: /usr/bin/qemu-system-x86_64 \
-name HTTP-BOOT-VM-1 \
-m 8192M \
-smp cpus=1 \
-enable-kvm \
-machine smm=off \
-boot order=c \
-bios /opt/gns3/images/QEMU/OVMF-RELEASE.fd \
Ugh this makes my eyes bleed. :/ Please never use the "-bios" option
with OVMF.

Anyway that's not our current topic here.

-drive file=/opt/gns3/projects/1a83274a-c57f-4337-8a0d-1e68a9312e9a/project-files/qemu/d8f37f0b-2b63-455f-b536-b309b9020e36/hda_disk.qcow2,if=ide,index=0,media=disk \
-uuid d8f37f0b-2b63-455f-b536-b309b9020e36 \
-vnc 0.0.0.0:3 \
-monitor tcp:127.0.0.1:41898,server,nowait \
-net none \
Seems inconsistent with your intent to HTTP Boot... At least superfluous
with the below, I'd think

-device virtio-net-pci,mac=0c:2e:9a:0e:36:00,netdev=gns3-0 \
Seems OK; so you are using virtio-net-pci.

-netdev socket,id=gns3-0,udp=127.0.0.1:10017,localaddr=127.0.0.1:10016 \
Unfortunately, I'm entirely unused to "-netdev socket", especially with
"udp=...". I only use "-netdev tap" (via libvirt).

-nographic \
-debugcon file:debug.log \
-global isa-debugcon.iobase=0x402

The OVMF log is empty, all the logs appear in attached qemu.log file.
Hmmm... Ah you mention "OVMF-RELEASE.fd" above. So that must be a
RELEASE build of OVMF, which indeed does not produce debug messages. Can
you try with DEBUG please?


I've did some debugging myself and found out the offending line is
here:
File: NetworkPkg/HttpBootDxe/HttpBootSupport.c#L1012
The error is handled here:
NetworkPkg/HttpBootDxe/HttpBootSupport.c#L1018
Yes, I checked those lines after reading your earlier message.

I asked for your command line and the OVMF debug log because I wanted to
see if you were using the iPXE SNP driver for virtio-net (you most
likely are, from the info thus far). It could be interesting to try the
built-in virtio-net driver, for one data point. (This would be a
front-end check.)

Second, I have no idea what's happening on the udp socket netdev
back-end. It could explain the virtual network glitches you are seeing.
I'm not sure.

Laszlo


Platform Variable hook library for Supporting UEFI Variable Resiliency

Wang, Sunny (HPS SW)
 

Hi all,

As the discussion in the email thread below, we would like to add a Platform Variable hook library for IBV/OEM to support the UEFI Variable Resiliency (protection, detection, and recovery for critical UEFI variable).

For your quick reference, I summarized the reasons why we need to do this below:
1. There are some guidelines and requirements in NIST 800-193 and other security guidelines for critical UEFI variables like BootOrder, so we need to make some changes to comply with them.
2. The current variable protection mechanism in EDK2 called "Variable Policy (EDKII_VARIABLE_LOCK_PROTOCOL and VarCheckLib)" can't satisfy our needs. Using VariableLock would cause issues with OSes, and VarCheckLib can't check the data. Therefore, we need to add code to check and override the changes that were made at runtime.
3. Since each platform has its defined critical data and its protection and recovery policies/actions, some changes need to be platform-specific. However, there is no hook function or interface consumed by the EDK2 variable driver for IBV/OEM to add platform changes. Therefore, we need to add a Platform Variable hook library.

Moreover, I checked this with Ray and will bring the details to this week's design meeting on 2/21. I also uploaded my slides to the link below for your further reference. Of course, if you have any questions, feel free to bring it to me anytime.
https://edk2.groups.io/g/devel/files/Designs/2020/0221/Platform%20Libraries%20for%20Supporting%20UEFI%20Variable%20Resiliency.pdf

Regards,
Sunny Wang

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Wang, Sunny (HPS SW)
Sent: Thursday, February 6, 2020 4:52 PM
To: discuss@edk2.groups.io; lersek@redhat.com; sean.brogan@microsoft.com; tim.lewis@insyde.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; ray.ni@intel.com
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Javier Martinez Canillas <javierm@redhat.com>; Peter Jones <pjones@redhat.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Subject: Re: [edk2-discuss] Lock BootOrder variable

Hi Lazlo,

Thanks for the comments and sorry for the delay. I was just back from my long vacation and was busy with some other stuff.

Yeah, locking BootOrder is not acceptable, so we would like to override or ignore the BootOrder change made by OS or non-trusted software at the next boot to protect and recover the BootOrder. In other words, locking variables will definitely not be used as a solution. We just want OS vendors to gracefully deal with all the error status from the runtime variable service. However, if you think RuntimeServicesSupported is good and clear enough for OS vendors to gracefully deal with this, I'm totally fine with not adding another description into UEFI specification.

As for the solution, you're also right about that it should be implemented as a platform code. However, since the system may have more UEFI variables (not only BootOrder) that are identified as critical data and needed to be protected as well, we would like to propose a platform variable hook library to add the hook function calls into the variable driver for IBV/OEM like us to implement the platform protection code.

Moreover, before submitting my patches, I think it would be better to further discuss this at the design meeting, so I will check this with Ray to find an available time slot and then present the details to you guys. The purpose of our proposal will be to have platform libraries for IBV/OEM to implement their code for complying with the NIST 800-193 and other security guidelines mentioned in the previous emails (Supporting the UEFI Variable Resiliency (protection, detection, and recovery)).

Regards,
Sunny Wang

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Saturday, January 4, 2020 1:48 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; sean.brogan@microsoft.com; tim.lewis@insyde.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>; Javier Martinez Canillas <javierm@redhat.com>; Peter Jones <pjones@redhat.com>
Subject: Re: [edk2-discuss] Lock BootOrder variable

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.
-
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fedk2.groups.io-252F
g-252Fdevel-252Ffiles-252FDesigns-252F2019-252F0516-26amp-3Bdata-3D02-
257C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77
faa2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241
153980473-26amp-3Bsdata-3DxjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ-
253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMd
GZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii
_NieuwsJZk8&s=6O-ZcjoIEhjvpzBGydrRy4RM6BCiLwpTVRmAlkphX-o&e=
However, It looks like we would still run into the OS installation failure with the current VariablePolicy protocol implementation. I didn't deeply look into the VariablePolicy protocol or give it a try, so I may overlook the solution in your implementation. Could you help point out where the code for solving OS installation failure is? The problem here is that OS doesn't gracefully deal with the locked UEFI variable, so we may not be able to return EFI_WRITE_PROTECTED to OS for the writes to BootOrder.


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

Regards,
Sunny Wang

-----Original Message-----
From: tim.lewis@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:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Ftian
ocore-252Fedk2-252Fblob-252Fmaster-252FMdeModulePkg-252FInclude-252FPr
otocol-252FVariableLock.h-26amp-3Bdata-3D02-257C01-257Csean.brogan-254
0microsoft.com-257C7a27e3cc7d754208afd108d77faa2a64-257C72f988bf86f141
af91ab2d7cd011db47-257C1-257C0-257C637118241153980473-26amp-3Bsdata-3D
avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg-253D-26amp-3Breserved-3D0&
d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f
8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii_NieuwsJZk8&s=ACauqOvz9A5G
8S3vH-bALwc4RPyfS1u8O2sza1_9Hbw&e=
A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.

2. Project Mu VariablePolicy protocol:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fmicr
osoft-252Fmu-5Fbasecore-252Fblob-252Frelease-252F201911-252FMdeModuleP
kg-252FInclude-252FProtocol-252FVariablePolicy.h-26amp-3Bdata-3D02-257
C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77faa
2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241153
980473-26amp-3Bsdata-3D14Wv-252B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c
-253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEM
dGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71I
i_NieuwsJZk8&s=xjXKoZxYjZwyWJrEHGS5jayMp6HNXhombPuvq7NNM8g&e=
Flexible policy based locking that can be implemented in various hardware architectures.

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

Thanks
Sean


-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
To: discuss@edk2.groups.io; sunnywang@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: HTTP boot failed on timeout

doron.bleiberg@...
 

I also need to mention that I've enabled the HTTP boot myself and compiled the project this way:

git clone https://github.com/tianocore/edk2.git edk2-stable201911
cd edk2-stable201911
git submodule update --init
make -C BaseTools
. edksetup.sh BaseTools

vi Conf/target.txt
ACTIVE_PLATFORM = OvmfPkg/OvmfPkgX64.dsc
TARGET_ARCH = X64
TOOL_CHAIN_TAG = GCC48
TARGET = RELEASE

vi OvmfPkg/OvmfPkgX64.dsc
DEFINE NETWORK_HTTP_BOOT_ENABLE = TRUE
BUILD_TARGETS = RELEASE

export EDK_TOOLS_PATH=$PWD/BaseTools
build -p OvmfPkg/OvmfPkgX64.dsc

And I'm taking the file:
Build/OvmfX64/RELEASE_GCC48/FV/OVMF.fd

Doron


Re: HTTP boot failed on timeout

doron.bleiberg@...
 

Some inputs:
Qemu version: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.34), Copyright (c) 2003-2008 Fabrice Bellard
Qemu CMD: /usr/bin/qemu-system-x86_64 -name HTTP-BOOT-VM-1 -m 8192M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -bios /opt/gns3/images/QEMU/OVMF-RELEASE.fd -drive file=/opt/gns3/projects/1a83274a-c57f-4337-8a0d-1e68a9312e9a/project-files/qemu/d8f37f0b-2b63-455f-b536-b309b9020e36/hda_disk.qcow2,if=ide,index=0,media=disk -uuid d8f37f0b-2b63-455f-b536-b309b9020e36 -vnc 0.0.0.0:3 -monitor tcp:127.0.0.1:41898,server,nowait -net none -device virtio-net-pci,mac=0c:2e:9a:0e:36:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:10017,localaddr=127.0.0.1:10016 -nographic -debugcon file:debug.log -global isa-debugcon.iobase=0x402

The OVMF log is empty, all the logs appear in attached qemu.log file.

I've did some debugging myself and found out the offending line is here:
File: NetworkPkg/HttpBootDxe/HttpBootSupport.c#L1012
The error is handled here: NetworkPkg/HttpBootDxe/HttpBootSupport.c#L1018

Though I'm using large file I didn't observed a problem in buffer or RAM size.

I've tried to add the requests "Connection: Keep-Alive" header with no change in result.

The boot download always terminates at the same spot.

10x,
Doron


Re: HTTP boot failed on timeout

Laszlo Ersek
 

On 02/15/20 22:24, doron.bleiberg@ecitele.com wrote:
Some additional inputs:
I'm running the boot from a QEMU VM. In the QEMU logs I see the following error during HTTP boot:
Error: Server response timeout.
BdsDxe: failed to load Boot0005 "UEFI HTTPv4 (MAC:0C2E9A0E3600)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(0C2E9A0E3600,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(): Not Found

I've also raised httpd server logging to trace6 but could not find anything pointing to a problem on this side. I'm only able to observe an error after the UEFI terminated the session, which is expected.
* Please specify
- your QEMU version,
- your full QEMU cmdline.

* Please capture the OVMF log by appending the following QEMU flags:

-debugcon file:debug.log -global isa-debugcon.iobase=0x402

and attach the log.

Thanks
Laszlo


Re: HTTP boot failed on timeout

doron.bleiberg@...
 

Some additional inputs:
I'm running the boot from a QEMU VM. In the QEMU logs I see the following error during HTTP boot:
Error: Server response timeout.
BdsDxe: failed to load Boot0005 "UEFI HTTPv4 (MAC:0C2E9A0E3600)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(0C2E9A0E3600,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(): Not Found

I've also raised httpd server logging to trace6 but could not find anything pointing to a problem on this side. I'm only able to observe an error after the UEFI terminated the session, which is expected.

Doron


Re: HTTP boot failed on timeout

doron.bleiberg@...
 

Hi Rebecca,

I'm running Apache httpd/2.4.6 (CentOS)
File size is: ~420MB

I did try to run Wireshark, however I was not able to see anything special. The traffic just stopped flowing at some point.

Doron


Re: HTTP boot failed on timeout

Rebecca Cran
 

What web server are you using? How large is the file you're trying to download?

You might be able to get more information about which is at fault by running a traffic analyzer application such as WireShark.


--
Rebecca Cran

On 2020-02-15 13:29, doron.bleiberg@ecitele.com wrote:
Hi Community,

I'm trying to use HTTP boot, the process starts and download is progressing until ~40% of the download is complete. However, every-time the download it terminated at the same spot.
I've tried to debug both the UEFI and the http server side and was not able to get into a conclusion on which side the problem is.
I did find out the the timeout happen at:
File - NetworkPkg/HttpBootDxe/HttpBootSupport.c
Line: 1012
Code:
//
// Poll the network until receive finish.
//
while (!HttpIo->IsRxDone && ((HttpIo->TimeoutEvent == NULL) || EFI_ERROR (gBS->CheckEvent (HttpIo->TimeoutEvent)))) {
Http->Poll (Http);
}

The while loop terminates due to timeout and the below code takes action:
if (!HttpIo->IsRxDone) {
//
// Timeout occurs, cancel the response token.
//
Http->Cancel (Http, &HttpIo->RspToken);
Status = EFI_TIMEOUT;

return Status;
}

Is there any timeout I can set to avoid it? Is the problem on UEFI or http server side?

Doron


HTTP boot failed on timeout

doron.bleiberg@...
 

Hi Community,

I'm trying to use HTTP boot, the process starts and download is progressing until ~40% of the download is complete. However, every-time the download it terminated at the same spot.
I've tried to debug both the UEFI and the http server side and was not able to get into a conclusion on which side the problem is.
I did find out the the timeout happen at:
File - NetworkPkg/HttpBootDxe/HttpBootSupport.c
Line: 1012
Code:
//
// Poll the network until receive finish.
//
while (!HttpIo->IsRxDone && ((HttpIo->TimeoutEvent == NULL) || EFI_ERROR (gBS->CheckEvent (HttpIo->TimeoutEvent)))) {
Http->Poll (Http);
}

The while loop terminates due to timeout and the below code takes action:
if (!HttpIo->IsRxDone) {
//
// Timeout occurs, cancel the response token.
//
Http->Cancel (Http, &HttpIo->RspToken);
Status = EFI_TIMEOUT;

return Status;
}

Is there any timeout I can set to avoid it? Is the problem on UEFI or http server side?

Doron


Re: [EXTERNAL] [edk2-discuss] Unit Test Framework for UEFI driver of RAID controller

Bret Barkelew
 

EDK2 has a native unit test framework based on CMocka (which at one point was Google’s straight-C testing framework). Would that work for you?

- Bret

From: sanket.goswami via Groups.Io<mailto:sanket.goswami=microchip.com@groups.io>
Sent: Tuesday, February 11, 2020 8:15 PM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Unit Test Framework for UEFI driver of RAID controller

Hi,
I'm trying to create Unit test framework for UEFI driver of PCI RAID controller and looking for a suitable tool for this.
I'm thinking of using googletest and googlemock frame work for this.
Has anyone used googlemock framework with UEFI? I wish to know if it's possible to integrate both in EDK build.
Please let me know if anyone has used other similar tools for unit test framework for UEFI.

Thanks,
Sanket


Unit Test Framework for UEFI driver of RAID controller

sanket.goswami@...
 

Hi,
I'm trying to create Unit test framework for UEFI driver of PCI RAID controller and looking for a suitable tool for this.
I'm thinking of using googletest and googlemock frame work for this.
Has anyone used googlemock framework with UEFI? I wish to know if it's possible to integrate both in EDK build.
Please let me know if anyone has used other similar tools for unit test framework for UEFI.

Thanks,
Sanket


Re: A problem with live migration of UEFI virtual machines

Alex Bennée <alex.bennee@...>
 

wuchenye1995 <wuchenye1995@gmail.com> writes:

Hi all,
We found a problem with live migration of UEFI virtual machines due to size of OVMF.fd changes.
Specifically, the size of OVMF.fd in edk with low version such as edk-2.0-25 is 2MB while the size of it in higher version such as edk-2.0-30 is 4MB.
When we migrate a UEFI virtual machine from the host with low version of edk2 to the host with higher one, qemu component will report an error in function qemu_ram_resize while
checking size of ovmf_pcbios: Length mismatch: pc.bios: 0x200000 in != 0x400000: Invalid argument.
We want to know how to solve this problem after updating the
version of edk2.
You can only migrate a machine that is identical - so instantiating a
empty machine with a different EDK image is bound to cause a problem
because the machines don't match.

--
Alex Bennée


A problem with live migration of UEFI virtual machines

"wuchenye1995
 

Hi all,
We found a problem with live migration of UEFI virtual machines due to size of OVMF.fd changes.
Specifically, the size of OVMF.fd in edk with low version such as edk-2.0-25 is *2MB* while the size of it in higher version such as edk-2.0-30 is *4MB*.
When we migrate a UEFI virtual machine from the host with low version of edk2 to the host with higher one, qemu component will report an error in function *qemu_ram_resize* while
checking size of ovmf_pcbios: *Length mismatch: pc.bios: 0x200000 in != 0x400000: Invalid argument.*
** We want to know how to solve this problem after updating the version of edk2.
Thank you.

Chenye Wu                                                                                                                                                                                                                                                             2020.2.12


Re: Filter non-UEFI drives

Tim Crawford
 

Thanks Ashish, that looks useful for keeping some of our custom logic out of MdeModulePkg. I've added it to my list of things to do for rebasing on edk2 master.


Re: Lock BootOrder variable

Bret Barkelew
 

Sunny,

Have you seen the work that we've proposed on the VariablePolicy RFC (in the devel and rfc mailing groups)? Would that work for your purposes?

Thanks!
- Bret


Re: Lock BootOrder variable

Wang, Sunny (HPS SW)
 

Hi Lazlo,

Thanks for the comments and sorry for the delay. I was just back from my long vacation and was busy with some other stuff.

Yeah, locking BootOrder is not acceptable, so we would like to override or ignore the BootOrder change made by OS or non-trusted software at the next boot to protect and recover the BootOrder. In other words, locking variables will definitely not be used as a solution. We just want OS vendors to gracefully deal with all the error status from the runtime variable service. However, if you think RuntimeServicesSupported is good and clear enough for OS vendors to gracefully deal with this, I'm totally fine with not adding another description into UEFI specification.

As for the solution, you're also right about that it should be implemented as a platform code. However, since the system may have more UEFI variables (not only BootOrder) that are identified as critical data and needed to be protected as well, we would like to propose a platform variable hook library to add the hook function calls into the variable driver for IBV/OEM like us to implement the platform protection code.

Moreover, before submitting my patches, I think it would be better to further discuss this at the design meeting, so I will check this with Ray to find an available time slot and then present the details to you guys. The purpose of our proposal will be to have platform libraries for IBV/OEM to implement their code for complying with the NIST 800-193 and other security guidelines mentioned in the previous emails (Supporting the UEFI Variable Resiliency (protection, detection, and recovery)).

Regards,
Sunny Wang

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Saturday, January 4, 2020 1:48 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; sean.brogan@microsoft.com; tim.lewis@insyde.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>; Javier Martinez Canillas <javierm@redhat.com>; Peter Jones <pjones@redhat.com>
Subject: Re: [edk2-discuss] Lock BootOrder variable

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.
-
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fedk2.groups.io-252F
g-252Fdevel-252Ffiles-252FDesigns-252F2019-252F0516-26amp-3Bdata-3D02-
257C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77
faa2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241
153980473-26amp-3Bsdata-3DxjJYipCUkrC19mz9D0eRqAJYAOB0DGBVK7kgn7fTXuQ-
253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMd
GZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii
_NieuwsJZk8&s=6O-ZcjoIEhjvpzBGydrRy4RM6BCiLwpTVRmAlkphX-o&e=
However, It looks like we would still run into the OS installation failure with the current VariablePolicy protocol implementation. I didn't deeply look into the VariablePolicy protocol or give it a try, so I may overlook the solution in your implementation. Could you help point out where the code for solving OS installation failure is? The problem here is that OS doesn't gracefully deal with the locked UEFI variable, so we may not be able to return EFI_WRITE_PROTECTED to OS for the writes to BootOrder.


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

Regards,
Sunny Wang

-----Original Message-----
From: tim.lewis@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:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Ftian
ocore-252Fedk2-252Fblob-252Fmaster-252FMdeModulePkg-252FInclude-252FPr
otocol-252FVariableLock.h-26amp-3Bdata-3D02-257C01-257Csean.brogan-254
0microsoft.com-257C7a27e3cc7d754208afd108d77faa2a64-257C72f988bf86f141
af91ab2d7cd011db47-257C1-257C0-257C637118241153980473-26amp-3Bsdata-3D
avZwx8B1gRbULoRQuFhAldnvYAe20QFzyhG802LRzcg-253D-26amp-3Breserved-3D0&
d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f
8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71Ii_NieuwsJZk8&s=ACauqOvz9A5G
8S3vH-bALwc4RPyfS1u8O2sza1_9Hbw&e=
A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.

2. Project Mu VariablePolicy protocol:
INVALID URI REMOVED
rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fmicr
osoft-252Fmu-5Fbasecore-252Fblob-252Frelease-252F201911-252FMdeModuleP
kg-252FInclude-252FProtocol-252FVariablePolicy.h-26amp-3Bdata-3D02-257
C01-257Csean.brogan-2540microsoft.com-257C7a27e3cc7d754208afd108d77faa
2a64-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637118241153
980473-26amp-3Bsdata-3D14Wv-252B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c
-253D-26amp-3Breserved-3D0&d=DwICaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=Z9cLgEM
dGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw&m=uWkd1_Wtepp1js5IwHPeUBVeN78J71I
i_NieuwsJZk8&s=xjXKoZxYjZwyWJrEHGS5jayMp6HNXhombPuvq7NNM8g&e=
Flexible policy based locking that can be implemented in various hardware architectures.

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

Thanks
Sean


-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
To: discuss@edk2.groups.io; sunnywang@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: Filter non-UEFI drives

Ashish Singhal
 

Hello Tim,

I had a similar issue some time back and after discussion with edk2 community, I added a new protocol to MdeModulePkg that allows platform-specific hooks to take care of this. Please refer to commit 972d88726410e21b1fff1a528854202c67e97ef1 to see what has been added.

In your implementation of RefreshAllBootOptions api, you can parse the auto enumerated boot options (generated by BmEnumerateBootOptions()) and return back only the ones which you want to use.

Thanks
Ashish

On Wed, Feb 5, 2020 at 02:59 PM, Tim Crawford wrote:


Hi all,

I'm looking for a way to filter boot options to only those that contain EFI
volumes. Right now, testing in QEMU, I see things like empty CD-ROM drives and
blank USB drives as boot options.

In IntelFrameworkModulePkg, I accomplished this by adding a call to
BdsLibGetBootableHandle() in BdsLibEnumerateAllBootOption(). If I didn't get
a handle from the device, I skipped building a boot option for it.

In MdeModulePkg, this seems to correspond to BmEnumerateBootOptions(). But I'm
unsure of how to filter out non-EFI drives here.
(BmIsLoadOptionPeHeaderValid()
in BmLoadOption.c sounds promising for what I want.)

Thanks,
Tim


Filter non-UEFI drives

Tim Crawford
 

Hi all,

I'm looking for a way to filter boot options to only those that contain EFI
volumes. Right now, testing in QEMU, I see things like empty CD-ROM drives and
blank USB drives as boot options.

In IntelFrameworkModulePkg, I accomplished this by adding a call to
BdsLibGetBootableHandle() in BdsLibEnumerateAllBootOption(). If I didn't get
a handle from the device, I skipped building a boot option for it.

In MdeModulePkg, this seems to correspond to BmEnumerateBootOptions(). But I'm
unsure of how to filter out non-EFI drives here. (BmIsLoadOptionPeHeaderValid()
in BmLoadOption.c sounds promising for what I want.)

Thanks,
Tim

741 - 760 of 888