Secure Boot lack shouldn't be a failure on older FW

[mirh]

I'm not really sure what changed between initial Secure Boot implementation that according to spec was also available in 2.0, and whatever microsoft refers with "updated policies to include time-authenticated variables, stronger keys" (http://cromwell-intl.com/linux/uefi.html) in 2.3.1C

But anyway at least according to revision history, SecureBootCertVariableNotFound should be totally normal in firmwares before 2.3.1.
Couldn't these steps be skipped entirely in these cases then?

It shouldn't be a problem to automatically know which EFI version is implemented, given it's one of the first lines printed in dmesg.
Alternatively, arch/x86/platform/efi/efi.c should have some ideas to query/test directly the thing from fwts.

[Alex Hung (alexhung)]

A change in 17.05.00 may have address your issue:

commit a94a9d60710ed6b28597e23d332d5658cd02fe08
Author: Ivan Hu <email address hidden>
Date: Tue May 16 16:30:48 2017 +0800

    uefi: securebootcert: warnings for secure boot variables not exist instead of failures

    Some firmwares like OVMF or EDKII may not create these UEFI variables when
    they are not enabled the secure boot, it won't affect any functions because the
    secure boot is not supported or enabled. So set the tests as warnings instead
    of failures for the readiness of secure boot.

Will you be able to test new fwts and share your results?

[mirh (mirh)]

Yes, it results fine-ish now.

Though, I'm still kind of left wondering if these tests should run at all - when SB is not only disabled, but really missing and of course not even advertised.