[PATCH 18/38] efi: Show all known UUIDs with CONFIG_CMD_EFIDEBUG

[Simon Glass]

Hi Heinrich,

On Fri, 31 Mar 2023 at 19:46, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 31. März 2023 03:16:06 MESZ schrieb Simon Glass <sjg at chromium.org>:
> >Hi Heinrich,
> >
> >On Fri, 31 Mar 2023 at 13:27, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >>
> >>
> >> Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass <sjg at chromium.org>:
> >> >Hi Heinrich,
> >> >
> >> >On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >> >>
> >> >>
> >> >>
> >> >> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg at chromium.org>:
> >> >> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
> >> >> >that all effects should be made to decode the dreaded UUIDs favoured by
> >> >> >UEFI.
> >> >> >
> >> >> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
> >> >> >
> >> >> >Signed-off-by: Simon Glass <sjg at chromium.org>
> >> >> >---
> >> >> >
> >> >> > lib/uuid.c | 2 +-
> >> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> >diff --git a/lib/uuid.c b/lib/uuid.c
> >> >> >index 96e1af3c8b00..ab30fbf9152f 100644
> >> >> >--- a/lib/uuid.c
> >> >> >+++ b/lib/uuid.c
> >> >> >@@ -255,7 +255,7 @@ static const struct {
> >> >> >               EFI_CERT_TYPE_PKCS7_GUID,
> >> >> >       },
> >> >> > #endif
> >> >> >-#ifdef CONFIG_EFI
> >> >> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> >> >> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> >> >> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> >> >> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
> >> >>
> >> >> None of these are used when not building the EFI app.
> >> >
> >> >So you think we should disable them? As I said above, enabling
> >> >debugging seems like a good reason to allow decoding of all of them.
> >> >
> >> >Regards,
> >> >SImon
> >>
> >> U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if shared by the preceding UEFI firmware.
> >>
> >> There are zillions other GUIDs that a vendor UEFI might use. But why should we care?
> >>
> >> I would rather drop these strings from the code base.
> >
> >I would far rather drop the UUIDs from the code base. Is that
> >possible? We should use a simple numeric tag, like 0, 1, 2, 3, 4 with
> >an associated descriptive string. Even using a 16-byte string would be
> >better than a UUID.
> >
> >While we have to put up with UUIDs, we need a way to make them
> >intelligible for us poor sods who need to decode boot-time traces[1]
> >and the like.
>
> The EFI spec uses GUIDs and these are strings you will find with Google. Natural numbers that have bo significance won't serve anybody. GUIDs not used inside U-Boot we should not care to translate as there are too many.

I think it is an interesting idea though, to have an internal register
of these things with an enum. Then U-Boot can just use that everywhere
and it is clear what it is, at least within the U-Boot code base.
Things that are not understood don't matter anyway, since we don't
have code for them.

Anyway, back to the original topic, as you can see from the trace
below, it is far too tedious for a human to decode the UUIDs. That is
what the computer is for.

But if this patch has no value, because the UUIDs I mention are never
shown, we can drop it.

Regards,
Simon


>
> >
> >Regards,
> >Simon
> >
> >[1]
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_locate_handle_ext(2,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, 0000000000000000,
> >000000007ecf4948, 000000007d6f3ba0)
> >    EFI: Exit: efi_locate_handle_ext: 0
> >    EFI: Entry efi_open_protocol(000000007ed25040,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed25040,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf49b8, 00000
> >0007ed33da0, 0000000000000000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4958,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_locate_protocol(96751a3d-72f4-41a6-a794-ed5d0e67ae6b,
> >0000000000000000, 000000007ecf4668)
> >    EFI: Exit: efi_locate_protocol: 14
> >    EFI: Entry efi_locate_handle_ext(2,
> >f541796d-a62e-4954-a775-9584f61b9cdd, 0000000000000000,
> >000000007ecf4638, 000000007d40be00)
> >    EFI: Exit: efi_locate_handle_ext: 14
> >    EFI: Entry efi_locate_handle_ext(2,
> >607f766c-7455-42be-930b-e4d76db2720f, 0000000000000000,
> >000000007ecf4638, 000000007d40be00)
> >    EFI: Exit: efi_locate_handle_ext: 14
> >    EFI: Entry efi_locate_protocol(f42f7782-012e-4c12-9956-49f94304f721,
> >0000000000000000, 000000007ecf43e8)
> >    EFI: Exit: efi_locate_protocol: 14