Hello, I have a question about user error reporting during SecureBoot image validation.

From my testing with OVMF/Secureboot, when an image to be loaded fails validation (i.e. due to missing or incorrect signature), it silently fails. i.e. there is no indication given to the user via the console. All that seems to be done as a result is an entry added to the Image Execution Information Table.

I see there used to be code implemented to give an indication (e.g. QUERY_USER_ON_SECURITY_VIOLATION), but it was deemed a violation of the UEFI spec and removed.


I didn't see any code in edk2 at present which appears to consume the data in the Image Execution Information Table (though I may have missed it).

The UEFI spec (Version 2.8, Section 32.4.2) briefly discusses an "agent that executes later" can consume the table data, but is vague about what this agent can/should do.

We'd like users to be able to see image validation failures and the reason for the failure. There are currently some DEBUG output statements in the code, but this is inadequate for general user applications.

Questions:

Is there any (planned) replacement for QUERY_USER_ON_SECURITY_VIOLATION support? i.e. to give users an indication of the image validation failure?

Is there any "agent" code (as I reference above) at present to process the Image Execution Information Table - or any work planned in this area?


What I envisioned is some HII code added to the Boot Manager to display the contents of the Image Execution Information Table in a human readable manner. Does this seem reasonable?

Thanks in advance for any insight/comments/etc.

-Aaron Young

On 09/11/19 01:41, aaron.young@... wrote:

 Hello, I have a question about user error reporting during SecureBoot
image validation.

 From my testing with OVMF/Secureboot, when an image to be loaded fails
validation (i.e. due to missing or incorrect signature), it silently
fails. i.e. there is no indication given to the user via the console.
All that seems to be done as a result is an entry added to the Image
Execution Information Table.

 I see there used to be code implemented to give an indication (e.g.
QUERY_USER_ON_SECURITY_VIOLATION), but it was deemed a violation of the
UEFI spec and removed.


 I didn't see any code in edk2 at present which appears to consume the
data in the Image Execution Information Table (though I may have missed
it).

 The UEFI spec (Version 2.8, Section 32.4.2) briefly discusses an "agent
that executes later" can consume the table data, but is vague about what
this agent can/should do.

 We'd like users to be able to see image validation failures and the
reason for the failure. There are currently some DEBUG output statements
in the code, but this is inadequate for general user applications.

 Questions:

 Is there any (planned) replacement for QUERY_USER_ON_SECURITY_VIOLATION
support? i.e. to give users an indication of the image validation failure?

 Is there any "agent" code (as I reference above) at present to process
the Image Execution Information Table - or any work planned in this area?


 What I envisioned is some HII code added to the Boot Manager to display
the contents of the Image Execution Information Table in a human
readable manner. Does this seem reasonable?

 Thanks in advance for any insight/comments/etc.

A special case of your question is covered, at the moment, as follows
("give users an indication of the image validation failure"):

- When a UEFI boot option is rejected due to secure boot verification,
the BDS driver reports a structured status code that carries the
LoadImage / StartImage failure code.

- ArmVirtQemu and OVMF are subscribed to the status code in question,
and report it to the UEFI console (which is multiplexed to graphics and
serial). If you have log capture enabled for the serial console, you can
see the error report later, even if it disappears quickly from the
console otherwise (e.g. because the next boot option succeeds and clears
the screen quickly).

Please see commit range 2df879827442..1797f32e0a19.

I have no other input on this.

Thanks
Laszlo