Add support for a LoadOpt Hive

[hughsie]

Right now we can only store a UCS2-LE path in the loadopt data for Shim to consume. We now also need to provide that, and a way for customers to add and remove options for kernel command line if we want to remove grub with a 1st stage switchroot/kexec-able kernel like shim.

The other problem is that real-world broken firmware sometimes pads or offsets the loadopt data meaning that we can’t parse strings reliably. We should also make sure that the data inside the hive has not been corrupted, but do not need to cryptographically sign it.

We could create a hive, similar to the BCD hive found in Windows, that includes an extensible and robust key value store:

struct ShimHive {
    magic: [u8; 4],      // “HIVE”
    header_version: u8,  // 0x01
    items_count: u8,     // number of items to parse
    items_offset: u8,    // for forwards and backwards compatibility
    crc32: u32,          // of the entire hive (excluding padding)
    items: [ShimHiveItems; items_count]
}
struct ShimHiveItem {
    key_length: u8,
    value_length: u32,
    // key string, no trailing NUL
    // value string, no trailing NUL
}

• We should start parsing ShimHiveItem from offset ShimHive.items_offset to allow us to add more header items to ShimHive in the future without breaking ABI.
• The ShimHive should normally be padded out to 512 bytes to ensure that SetVariable writes are as atomic as possible. The padding should be NUL characters.
• If the hive is not present in the loadopt then it is loaded from the ESP, if it exists – perhaps in /EFI/$x/shim.env (normal path mangling like for second stage etc). This allows us to workaround hardware bugs and still boot an installer.

[hughsie]

@vathpela what did you call the key for the path? i.e. the UCS-2 thing we store already? i.e. Path, PATH etc?

[vathpela]

path and cmdline are the two I've got defined so far.