uefi-ssp-policy: Add a new plugin to detect missing SkuSiPolicy attributes

[hughsie]

Fixes #7329

Type of pull request:

• New plugin (Please include new plugin checklist)
• Code fix
• Feature
• Documentation

[hughsie]

@jsetje some review most welcome please

[hughsie]

@jsetje does this look sane?

[superm1]

premature, no? I don't see any code in here calling out the fix.

[hughsie]

Ohh fu_uefi_ssp_policy_plugin_fix_host_security_attr does exist -- apparently by setting the SSPPolicy key to 1 on next reboot shim will create the SkuSiPolicyVersion and SkuSiPolicyUpdateSigners -- although it doesn't seem to work for me at all.

[hughsie]

@vathpela can you see anything fishy here? I can't get shim to set the SkuSiPolicyVersion or SkuSiPolicyUpdateSigners keys and I'm not super sure how to debug shim. Thanks!

[superm1]

I think you need to check whether SSPPolicy already exists though don't you? It can only be fixed if the file doesn't exist.

[superm1]

Can you use the dummy efivars interface for a self test? Then you can cover existing variables, junk variables, all the permutations we might see in the wild.

[hughsie]

@superm1 talking of testing -- do we have a plan for getting coverage back? At least physiologically seeing a number "go down" means we're more likely to write tests.

[superm1]

@superm1 talking of testing -- do we have a plan for getting coverage back? At least physiologically seeing a number "go down" means we're more likely to write tests.

I'm trying to remember why it broke. It was some random bug in Debian we couldn't figure out right? Maybe we should just try to turn it back on in a PR and see what happens.

[superm1]

This is great! Can you add a second test of no Windows in the boot order?

[sei-vsarvepalli]

Look at SkuSiPolicyVersion perhaps - https://support.microsoft.com/en-us/topic/kb5027455-guidance-for-blocking-vulnerable-windows-boot-managers-522bb851-0a61-44ad-aa94-ad11119c5e91

SKU SiPolicy Variables

This policy uses two UEFI variables stored under the EFI Namespace/Vendor
GUID(SECUREBOOT_EFI_NAMESPACE_GUID):

#define SECUREBOOT_EFI_NAMESPACE_GUID \

{0x77fa9abd, 0x0359, 0x4d32, \

{0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}};

SkuSiPolicyVersion

is of type ULONGLONG/UInt64 at runtime

is defined by <VersionEx>2.0.0.2</VersionEx> within policy XML in the form of (MAJOR.MINOR.REVISION.BUILDNUMBER)

It is translated into ULONGLONG as

((major##ULL << 48) + (minor##ULL << 32) + (revision##ULL << 16) + buildnumber)

Each version number has 16 bits, so it has a total of 64 bits.
..
Namespace Guid:

77fa9abd-0359-4d32-bd60-28f4e78f784b

[jsetje]

I assume you're running a sufficiently new shim? The SkuSi support went into 15.8. Here's the code in mokutil that sets the variable: https://github.com/lcp/mokutil/blob/master/src/mokutil.c#L1792 the attributes probably matter.

Also, the interface I've been trying to preserve is mokutil not inherently setting the variables, although I'm willing to promote that by adding an appropriate comment to where shim consumes the variables.

Oh, the SkuSi variables are all BS variables only. I don't think they get mirrored to RT counterparts, since they aren't really part of MOK, although perhaps they should -- which would open the question of whether or not they should be measured (only?) when the Windows CA is trusted, which adds quite a bit of complexity. Hmm.

[jsetje]

I would think that would work.