Re: dirent always returns NULL when opening a directory, errno is 0

Laszlo Ersek

On 01/24/20 09:52, Jack Bruienne wrote:
I’m testing out running some code under the EFI environment to learn about writing EFI applications. I’m trying to list files in a directory on the filesystem using the dirent API provided with LibStd in EDK II. I have successfully compiled the code and linked with all required libraries, but I keep getting an issue where opendir() is always returning NULL. When checking the value of errno, it’s still EOK anyway. Here’s the code I’m using:

struct dirent *dir;
char * path = fixpath(old_path); // converts "/path/to/dir" to "FS0:\path\to\dir"
DIR * d = opendir(path);
if (d) {
for (int i = 0; (dir = readdir(d)) != NULL; i++) {
// process file entries
}
closedir(d);
} else err(path, "Not a directory");

When this code is run, it ends up calling err() and showing a message on the screen ("FS0:\: Not a directory (0)") instead of processing the file entries in the dirent structure. Are there any known bugs with the EDK II implementation of dirent? If so, how can I rewrite my code to use native EFI calls instead of dirent?

I am using the stable201911 version of EDK II with the latest edk2-libc, and I'm compiling under macOS using a Linux cross-compilation toolchain. The built EFI application is run under QEMU x86_64 with an OVMF firmware built with the same toolchain.
I think the fixpath() call is superfluous and wrong. As far as I
remember, when programming against edk2-libc, edk2-libc places some
directory structure requirements on the underlying UEFI filesystem.
Therefore manual conversion of pathnames should not be necessary;
instead it is on the provider of the underlying UEFI filesystem that
needs to place files in the right spots.

Let me see... Yes, please refer to section "TARGET-SYSTEM INSTALLATION"
in "StdLib/ReadMe.txt", in the edk2-libc project (with master @
61687168fe02).

It seems that, using StdLib, you can only refer to files that are on the
same filesystem that the executable was loaded from.

Thanks
Laszlo

dirent always returns NULL when opening a directory, errno is 0

Jack Bruienne

I’m testing out running some code under the EFI environment to learn about writing EFI applications. I’m trying to list files in a directory on the filesystem using the dirent API provided with LibStd in EDK II. I have successfully compiled the code and linked with all required libraries, but I keep getting an issue where opendir() is always returning NULL. When checking the value of errno, it’s still EOK anyway. Here’s the code I’m using:

struct dirent *dir;
char * path = fixpath(old_path); // converts "/path/to/dir" to "FS0:\path\to\dir"
DIR * d = opendir(path);
if (d) {
for (int i = 0; (dir = readdir(d)) != NULL; i++) {
// process file entries
}
closedir(d);
} else err(path, "Not a directory");

When this code is run, it ends up calling err() and showing a message on the screen ("FS0:\: Not a directory (0)") instead of processing the file entries in the dirent structure. Are there any known bugs with the EDK II implementation of dirent? If so, how can I rewrite my code to use native EFI calls instead of dirent?

I am using the stable201911 version of EDK II with the latest edk2-libc, and I'm compiling under macOS using a Linux cross-compilation toolchain. The built EFI application is run under QEMU x86_64 with an OVMF firmware built with the same toolchain.

Re: EFI Group Event Callback Order

Li, Walon

Thanks for your explanation, it's very clear.
Is it possible to update spec that makes unspecified behavior to specified? I know the implementation is in accordance with spec but add some comments can make programmer use this mechanism flexible.

Thanks!
Walon

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Saturday, January 18, 2020 2:19 AM
To: Li, Walon <walon.li@hpe.com>; discuss@edk2.groups.io
Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Spottswood, Jason <jason.spottswood@hpe.com>; Shifflett, Joseph <joseph.shifflett@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>
Subject: Re: [edk2-discuss] EFI Group Event Callback Order

On 01/17/20 14:24, Li, Walon wrote:
Laszlo,

Yes, we can specific TPL to adjust callback order. But sometimes, an
event has many callbacks like as ReadyToBoot and TPL level may not
satisfy purpose. In UEFI spec CreateEvent chapter, also mentioned "The
functions in these queues are invoked in FIFO order". So, if it define
clearly in UEFI spec, LIFO or FIFO, we may use driver dependency to
decide which driver's event registration priority and specific
callback order indirectly.
The FIFO order refers to something else. Here's a larger citation:

When the event is signaled, firmware changes its state to "signaled"
and, if EVT_NOTIFY_SIGNAL is specified, places a call to its
notification function in a FIFO queue. There is a queue for each of
the "basic" task priority levels defined in Section 7.1
(TPL_CALLBACK, and TPL_NOTIFY). The functions in these queues are
invoked in FIFO order, starting with the highest priority level
queue and proceeding to the lowest priority queue that is unmasked
by the current TPL.

It means that, within a given TPL, the notification function invocation order will reflect the enqueueing (= signaling) order.

But the spec does not specify the *signaling* order for such events that belong to the same event group, when one of those events is signaled.
The spec says,

Event groups are collections of events identified by a shared
EFI_GUID where, when one member event is signaled, all other events
are signaled and their individual notification actions are taken (as
described in CreateEvent). All events are guaranteed to be signaled
functions will be executed in the order specified by their
NotifyTpl.

So if you have two events, A and B, and they belong to the same event group G, and NotifyTpl is the same for both, then if you signal either A or B, then the notification functions may be queued, *and invoked*, in either (A, B), or (B, A), order. The invocation order will reflect the queueing order, yes, but the latter is unspecified, when you go through an event group.

Thanks
Laszlo

Re: EFI Group Event Callback Order

Laszlo Ersek

On 01/17/20 14:24, Li, Walon wrote:
Laszlo,

Yes, we can specific TPL to adjust callback order. But sometimes, an
event has many callbacks like as ReadyToBoot and TPL level may not
satisfy purpose. In UEFI spec CreateEvent chapter, also mentioned
"The functions in these queues are invoked in FIFO order". So, if it
define clearly in UEFI spec, LIFO or FIFO, we may use driver
dependency to decide which driver's event registration priority and
specific callback order indirectly.
The FIFO order refers to something else. Here's a larger citation:

When the event is signaled, firmware changes its state to “signaled”
and, if EVT_NOTIFY_SIGNAL is specified, places a call to its
notification function in a FIFO queue. There is a queue for each of
the “basic” task priority levels defined in Section 7.1
(TPL_CALLBACK, and TPL_NOTIFY). The functions in these queues are
invoked in FIFO order, starting with the highest priority level
queue and proceeding to the lowest priority queue that is unmasked
by the current TPL.

It means that, within a given TPL, the notification function invocation
order will reflect the enqueueing (= signaling) order.

But the spec does not specify the *signaling* order for such events that
belong to the same event group, when one of those events is signaled.
The spec says,

Event groups are collections of events identified by a shared
EFI_GUID where, when one member event is signaled, all other events
are signaled and their individual notification actions are taken (as
described in CreateEvent). All events are guaranteed to be signaled
functions will be executed in the order specified by their
NotifyTpl.

So if you have two events, A and B, and they belong to the same event
group G, and NotifyTpl is the same for both, then if you signal either A
or B, then the notification functions may be queued, *and invoked*, in
either (A, B), or (B, A), order. The invocation order will reflect the
queueing order, yes, but the latter is unspecified, when you go through
an event group.

Thanks
Laszlo

Re: EFI Group Event Callback Order

Tomas Pilar (tpilar)

I had to solve this for myself by creating a PostReadyToBoot event that is signalled by my ReadyToBoot callback. That meant that my PostReadyToBoot callbacks got executed after all the ReadyToBoot event functions.

Cheers,
Tom
________________________________________
From: discuss@edk2.groups.io <discuss@edk2.groups.io> on behalf of Li, Walon <walon.li@hpe.com>
Sent: 17 January 2020 13:24
To: discuss@edk2.groups.io; Laszlo Ersek
Cc: Wei, Kent (HPS SW); Wang, Sunny (HPS SW); Chang, Abner (HPS SW/FW Technologist); Spottswood, Jason; Shifflett, Joseph; Haskell, Darrell; Wiginton, Scott
Subject: Re: [edk2-discuss] EFI Group Event Callback Order

Laszlo,

Yes, we can specific TPL to adjust callback order. But sometimes, an event has many callbacks like as ReadyToBoot and TPL level may not satisfy purpose.
In UEFI spec CreateEvent chapter, also mentioned "The functions in these queues are invoked in FIFO order". So, if it define clearly in UEFI spec, LIFO or FIFO, we may use driver dependency to decide which driver's event registration priority and specific callback order indirectly.

Thank you,
Walon

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Friday, January 17, 2020 4:09 PM
To: discuss@edk2.groups.io; Li, Walon <walon.li@hpe.com>
Subject: Re: [edk2-discuss] EFI Group Event Callback Order

On 01/16/20 09:32, Li, Walon wrote:
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,
);
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
TestCallback2,
NULL,
);
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;
}

CoreAcquireEventLock ();

if ((Type & EVT_NOTIFY_SIGNAL) != 0x00000000) {
//
// The Event's NotifyFunction must be queued whenever the event is signaled
//
}

Thank you,
Walon

It's unspecified. Implementations may differ, and an implementation isn't even required to be self-consistent wrt. the order.

Ordering is only specified in terms of TPLs.

Thanks
Laszlo

The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.

Re: EFI Group Event Callback Order

Li, Walon

Laszlo,

Yes, we can specific TPL to adjust callback order. But sometimes, an event has many callbacks like as ReadyToBoot and TPL level may not satisfy purpose.
In UEFI spec CreateEvent chapter, also mentioned "The functions in these queues are invoked in FIFO order". So, if it define clearly in UEFI spec, LIFO or FIFO, we may use driver dependency to decide which driver's event registration priority and specific callback order indirectly.

Thank you,
Walon

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Friday, January 17, 2020 4:09 PM
To: discuss@edk2.groups.io; Li, Walon <walon.li@hpe.com>
Subject: Re: [edk2-discuss] EFI Group Event Callback Order

On 01/16/20 09:32, Li, Walon wrote:
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,
);
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
TestCallback2,
NULL,
);
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;
}

CoreAcquireEventLock ();

if ((Type & EVT_NOTIFY_SIGNAL) != 0x00000000) {
//
// The Event's NotifyFunction must be queued whenever the event is signaled
//
}

Thank you,
Walon

It's unspecified. Implementations may differ, and an implementation isn't even required to be self-consistent wrt. the order.

Ordering is only specified in terms of TPLs.

Thanks
Laszlo

Re: EFI Group Event Callback Order

Laszlo Ersek

On 01/16/20 09:32, Li, Walon wrote:
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,
);
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
TestCallback2,
NULL,
);
I'm curious the order of callback.
It's unspecified. Implementations may differ, and an implementation
isn't even required to be self-consistent wrt. the order.

Ordering is only specified in terms of TPLs.

Thanks
Laszlo

Re: Is possible to obtain assembly output from modules?

alejandro.estay@...

That did exactly I wanted. Thanks Laszlo.

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,

);

Status = gBS->CreateEventEx (

EVT_NOTIFY_SIGNAL,

TPL_CALLBACK,

TestCallback2,

NULL,

);

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;

}

CoreAcquireEventLock ();

if ((Type & EVT_NOTIFY_SIGNAL) != 0x00000000) {

//

// The Event's NotifyFunction must be queued whenever the event is signaled

//

}

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 like
scanf()? For example, print() shares some things with printf(), but I
can't find any related to input working that way.
I 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:
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

However asmdump.asm only contains listing for the last file compiled in the module Is there a better way to do this?
The 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

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.

Thanks

Re: Lock BootOrder variable

Laszlo Ersek

On 01/03/20 18:48, Laszlo Ersek wrote:

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.
Just 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,

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>
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.
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.

A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.

2. Project Mu VariablePolicy protocol: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fblob%2Frelease%2F201911%2FMdeModulePkg%2FInclude%2FProtocol%2FVariablePolicy.h&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&amp;sdata=14Wv%2B8VbDcwwAcuDQ2rG0V8g561YSDw9By26gIFIr8c%3D&amp;reserved=0
Flexible policy based locking that can be implemented in various hardware architectures.

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

Thanks
Sean

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
To: discuss@edk2.groups.io; sunnywang@hpe.com
Subject: [EXTERNAL] Re: [edk2-discuss] Lock BootOrder variable

The UEFI define the BootOrder variable with NV+BS+RT attributes, so its not possible to lock this variable, you can try to delete the BootOrder variable and then set the variable with AT attribute, which will probably will result in an undefined behavior. OVMF just recreates the the BootOrder with NV+BS+RT again, then any code which can call Runtime Services will be able to change BootOrder again.

A possible method is too use a signed loader which have your own 'BootOrder' hardcoded.

-----Original Message-----
From: Samer El-Haj-Mahmoud [mailto:Samer.El-Haj-Mahmoud@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Sunny,

Looks like this is a Windows Hardware Compatibility Specification requirement: https://go.microsoft.com/fwlink/?linkid=2086856 , in Systems.pdf, under System.Fundamentals.Security.DGCG.DeviceGuard - Firmware BIOS lockdown

I am aware of some proprietary implementations of "Lock Boot Order" as a firmware/UEFI setting, but not a standard method defined in the spec.

Also, NSA has some guidelines on locking down UEFI boot order using whatever firmware settings to disable any undesired boot sources (such as externally available USB or network ports): https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.nsa.gov_Portals_70_documents_what-2Dwe-2Ddo_cybersecurity_professional-2Dresources_csi-2Duefi-2Dlockdown.pdf%26d%3DDwIFAg%26c%3DC5b8zRQO1miGmBeVZ2LFWg%26r%3DZ9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N3205AYw%26m%3DasfixhAVUFNND_WEH4KyE0iVEY8HgOOvdPb6NrNwOUQ%26s%3D-rAbAKmK6iJFSGCadTldga_88zXzHJY2rz7Zmyh_lSM%26e&;data=02%7C01%7Csean.brogan%40microsoft.com%7C7a27e3cc7d754208afd108d77faa2a64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637118241153980473&amp;sdata=3F6hFgqkkXYyeqS%2BiHp2TfYNGK9J82AZdWwX1mZNc5w%3D&amp;reserved=0= .

Thanks,

Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu:
Hi All,

Is there any spec'd way that we can use to lock some UEFI variables like BootOrder without breaking OS installation and OS functionalities?

For some security reasons and customer use cases, we need to let system firmware completely own some UEFI variables like BootOrder. In other words, we don't want some UEFI variables to be controlled by the OS using the UEFI runtime service SetVariable. In addition, we tried to lock the BootOrder variable, but it would break OS installation or some OS functionalities.

By the way, we will bring this need to USWG if there is no existing spec'd way for satisfying this need.

Regards,
Sunny Wang

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

alejandro.estay@...

Thank you very much Laszlo, and Happy New Year.

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

charptr=&buffer_char[0];

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

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

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

Laszlo Ersek

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

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

if (call_status != EFI_SUCCESS)
{
return call_status;
}
else
{
call_status=ChangeFrequency(EFI_DEFAULT_BEEP_ALTFREQUENCY);

GenerateBeep();

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

This call looks invalid (undefined behavior), likely due to a copy/paste
error. It should be:

^^^^^^^^^ ^^^^^^^^^

and not

^^^^ ^^^^^^^^^

HTH,
Laszlo

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

return EFI_SUCCESS;
}

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

alejandro.estay@...

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

// Piezo speaker related
#define EFI_SPEAKER_CONTROL_PORT 0x61
#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_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 |= 0x03;
IoWrite8( EFI_SPEAKER_CONTROL_PORT, Data) ;
}

VOID turn_spkr_off( VOID )
{
UINT8 Data;

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;
FileSystem->OpenVolume(FileSystem, &Root);
if (call_status != EFI_SUCCESS)
{
return call_status;
}
else
{
call_status=ChangeFrequency(EFI_DEFAULT_BEEP_ALTFREQUENCY);

GenerateBeep();

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

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.

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
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

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

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

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

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

2. Boot the target system into the UEFI shell

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

Starting UDK's SoftDebugger + Windbg does not seem to change, regardless of
whether that is done before or after (3). Windbg prints this

Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
WARNING: An old EXDIv1 server has been detected. Debugger will use the
compatibility layer.

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.

Best,
Satoshi

Re: Lock BootOrder variable

Wang, Sunny (HPS SW)

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

-----Original Message-----
From: tim.lewis@insyde.com <tim.lewis@insyde.com>
Sent: Thursday, December 19, 2019 1:03 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; sean.brogan@microsoft.com; phlamorim@riseup.net; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@arm.com>
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>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Sunny --

I am curious. Can you point me to the portion of the NIST 800-193 that has guidelines the UEFI boot order (or similar data)? Is this a case when the owner of the platform is not the user of the platform?

Thanks,

Tim

-----Original Message-----
From: Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Sent: Friday, December 13, 2019 12:55 AM
To: tim.lewis@insyde.com; discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Thanks, guys.

Hi Samer,
Thanks for checking this and giving great information. I just knew that NIST 800-193 has some guidelines for locking down the UEFI boot order. The requirements and guidelines you added further proved the need of locking boot order.

Hi Sean,
Actually, I did check the Project Mu VariablePolicy protocol when you guys proposed this in the design meeting. This is definitely a good enhancement because I also ran into the problems mentioned in slides.
- https://edk2.groups.io/g/devel/files/Designs/2019/0516
However, It looks like we would still run into the OS installation failure with the current VariablePolicy protocol implementation. I didn't deeply look into the VariablePolicy protocol or give it a try, so I may overlook the solution in your implementation. Could you help point out where the code for solving OS installation failure is? The problem here is that OS doesn't gracefully deal with the locked UEFI variable, so we may not be able to return EFI_WRITE_PROTECTED to OS for the writes to BootOrder.

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

Regards,
Sunny Wang

-----Original Message-----
From: tim.lewis@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Friday, December 13, 2019 10:26 AM
To: discuss@edk2.groups.io; sean.brogan@microsoft.com; phlamorim@riseup.net; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Sean --

Since you already have published code and it is already publicly available, then I suggest that you bring it to USWG now, rather than later.

Thanks,

Tim

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sean via Groups.Io
Sent: Thursday, December 12, 2019 5:31 PM
To: discuss@edk2.groups.io; phlamorim@riseup.net; sunnywang@hpe.com
Subject: Re: [edk2-discuss] Lock BootOrder variable

Sunny,

There are two other public, non-uefi spec solutions I am aware of.

1. Edk2 VariableLock protocol: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h
A relatively limited solution with hard coded lock points tied to edk2 SMM variable store.

2. Project Mu VariablePolicy protocol: https://github.com/microsoft/mu_basecore/blob/release/201911/MdeModulePkg/Include/Protocol/VariablePolicy.h
Flexible policy based locking that can be implemented in various hardware architectures.

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

Thanks
Sean

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Paulo Henrique Lacerda de Amorim via Groups.Io
Sent: Thursday, December 12, 2019 12:53 PM
To: discuss@edk2.groups.io; sunnywang@hpe.com
Subject: [EXTERNAL] Re: [edk2-discuss] Lock BootOrder variable

The UEFI define the BootOrder variable with NV+BS+RT attributes, so its not possible to lock this variable, you can try to delete the BootOrder variable and then set the variable with AT attribute, which will probably will result in an undefined behavior. OVMF just recreates the the BootOrder with NV+BS+RT again, then any code which can call Runtime Services will be able to change BootOrder again.

A possible method is too use a signed loader which have your own 'BootOrder' hardcoded.

-----Original Message-----
From: Samer El-Haj-Mahmoud [mailto:Samer.El-Haj-Mahmoud@arm.com]
Sent: Friday, December 13, 2019 12:30 AM
To: discuss@edk2.groups.io; Wang, Sunny (HPS SW) <sunnywang@hpe.com>
Cc: Spottswood, Jason <jason.spottswood@hpe.com>; Wiginton, Scott <scott.wiginton@hpe.com>; Bodner, James <james.bodner@hpe.com>; Haskell, Darrell <darrell.haskell@hpe.com>
Subject: RE: [edk2-discuss] Lock BootOrder variable

Sunny,

Looks like this is a Windows Hardware Compatibility Specification requirement: https://go.microsoft.com/fwlink/?linkid=2086856 , in Systems.pdf, under System.Fundamentals.Security.DGCG.DeviceGuard - Firmware BIOS lockdown

I am aware of some proprietary implementations of "Lock Boot Order" as a firmware/UEFI setting, but not a standard method defined in the spec.

Also, NSA has some guidelines on locking down UEFI boot order using whatever firmware settings to disable any undesired boot sources (such as externally available USB or network ports): https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf .

Thanks,

Em 12/12/2019 05:49, Wang, Sunny (HPS SW) escreveu:
Hi All,

Is there any spec'd way that we can use to lock some UEFI variables like BootOrder without breaking OS installation and OS functionalities?

For some security reasons and customer use cases, we need to let system firmware completely own some UEFI variables like BootOrder. In other words, we don't want some UEFI variables to be controlled by the OS using the UEFI runtime service SetVariable. In addition, we tried to lock the BootOrder variable, but it would break OS installation or some OS functionalities.

By the way, we will bring this need to USWG if there is no existing spec'd way for satisfying this need.

Regards,
Sunny Wang

 741 - 760 of 859