Feature / bootkit does not need keyset access

[smoser]

I'm marking this as 'draft'.
It heavily re-works bootkit build.

See the README.md for the changes .

The big thing is that the published bootkit wont have any certificates inside artifacts and wont have any signed content.

The bootkit artifacts are then combined with a keyset in the 'customized' layer.

[smoser]

This is still work in progress, but a lot further along.

What is here:

1. restoring 'oci-boot' tool to bootkit ... this probably needs some further work though
2. moving all of the 'customization' out of the built layers. Now, a 'make custom' requires KEYSET_D to be set, but then can create all the customized artifacts needed for booting (shim, uki, ovmf-vars).
3. shell script tool in tools/custbk that has a sane interface to creating those customized artifacts from the uncustomized bootkit output (see its usage in layers/custom/custom.yaml).
4. add useful api for doing things with bootkit artifacts, like signing, updating firmware ...
5. a tool 'bkcust' which is written in go that uses that api. There is usage of 'bkcust' inside layers/custom/custom.yaml also.

The thing that is missing from the api and the 'bkcust' right now is the initrd "combining". Everything else is there.

What is TODO:

• initrd combining. I have started that, and had some idas on initrd writer and reader. but they're not all the way thought through.
• more knowledge of where files are in bootkit as part of the bootkit api. Rigth now, the user has to know where the kernel initrd... and things are in a bootkit output in order to pass them correctly to the api. a bootkit api should have "just works" behavior for working wtih a bootkit output.
• remove dependencies
  • the 'firmware' api calls out 'virt-fw-vars', so the user has to have that installed in order to use that. 2 ways to get rid of that dependency: start implementing that in go, or include the python package inside the golang code. a zip of the pure python package could be executed instead of depending on the system (https://docs.python.org/3/library/zipapp.html)
  • objcopy is invoked... that could use something else
  • oci-boot has some dependencies

Plan for it's use in machine:

• machine (maybe via 'trust' command) would pull a 'bootkit' artifacts to a local directory and the create the customized artifacts much like is shown in custom.yaml
• oci-boot probably needs improvement too (so that trust can use its api to do the thngs to build a bootable media).