firmware_uefi: add diagnostics service for uefi logs

[maheeraeron]

This PR focuses on a new diagnostics service for firmware_uefi.

UEFI will write the GPA of the advanced logger buffer (which we formally call EFI Diagnostics here) to an Io port intercept called SET_EFI_DIAGNOSTICS_GPA.

UEFI will also write to a different Io port intercept called PROCESS_EFI_DIAGNOSTICS, which signals us to process the EFI Diagnostics buffer.

The diagnostics subsystem's role is to read into guest memory from the specified GPA, collect advanced logger entries and log them to our tracing facilities. This will get triggered by the following conditions:

• UEFI encounters a failure (guest driven via PROCESS_EFI_DIAGNOSTICS)
• UEFI fails to boot any device (guest driven via PROCESS_EFI_DIAGNOSTICS)
• UEFI reaches exit boot services

[mebersol]

process_diagnostics

let's fuzz this

[chris-oo]

Is it possible to add a vmm_tests test for this, where we just see that uefi logged something?

[jstarks]

(GitHub is misbehaving, so I can't attach this to the .validate call in your code):

I am violently against "validate" methods that check things and don't return a value.

1. It's extremely unclear what invariants you're validating. What are the post conditions on this method? The reviewer can't tell from the call site--they have to go read the code to see what you're actually validating. That's a recipe for failing to validate some important thing.

2. After you validate some invariant on untrusted data, you typically have everything you need to produce a parsed representation. So you end up duplicating work in the "parsing" step. Better to just have a parse/process function that both validates and extracts the (now validated) data.

In this case, I would suggest just getting rid of these validation functions and just putting the checks inline, next to the code that relies on the validation having been performed.

[jstarks]

No arbitrary strings in error types. Again, either use anyhow or enumerate your error conditions.

[maheeraeron]

Is it possible to add a vmm_tests test for this, where we just see that uefi logged something?

That's a good idea. I think these would be part of openhcl_uefi tests? A couple questions:

• Does this fit the scope of this PR? --> yes, this should be pretty small

• Do we have a way to specify no_vhd in an openvmm_test? (useful to simulate a test for logs with no boot devices) --> yes, just specify "none"

• Do we have example tests that look for specific tracing::info!() logs? --> yes, chris just added this 2 days ago to look through kmsg

[chris-oo]

use /// doc comments here, please. Also, can we require doc comments?