Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature / bootkit does not need keyset access #30

Merged
merged 1 commit into from
Aug 18, 2023
Merged

Feature / bootkit does not need keyset access #30

merged 1 commit into from
Aug 18, 2023

Conversation

smoser
Copy link
Collaborator

@smoser smoser commented May 4, 2023

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 smoser changed the title Feature/restore the api Feature / bootkit does not need keyset access May 4, 2023
@smoser
Copy link
Collaborator Author

smoser commented Jun 23, 2023

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).

Publish uncustomized content, partial API implementation
a421197 
Lots of things here.
 * Publish uncustomized content. Previously content in the published 'bootkit'
   layer was signed with snakeoil "keyset". Now we publish only the uncustomized
   content. Building customized content is possible with 'make cust' (see
   below)

 * Add 'make cust' target to build customized content.

   By running 'make cust KEYSET_D=/path/to/keyset', the user can create all the
   customized output locally.  This currently does require to build all layers,
   so it isn't a great solution.

   Future changes would hopefully allow setting building of a customized layer
   using the artifacts in a published bootkit layer.  There is a start of that
   in layers/custom.yaml, see the CUSTOM_BOOTKIT_INPUT option.  Hopefully we
   can do a better job there.

   In the meantime, the shell script 'tools/custbk' has a reasonable user
   interface and only a few dependencies.
     * python3
     * objcopy
     * virt-fw-vars (from virt-firmware python package)
     * cert-to-efi-sig-list (efitools)

   Output of 'cust' build is a layer with:

     customized/ovmf-vars.fd
     customized/ovmf-code.fd
     customized/kernel.efi
     customized/shim.efi

 * A 'bkcust' golang tool that does many of the operations involved in the
   custom.yaml file.  The goal is to replace the use of the tools/custbk
   shell script with the 'bkcust' golang, which has fewer dependencies.

   There is more work to do on this tool.

 * Beginings of an API.

   There is a reasonable API now for working with the bootkit artifacts.

     * firmware(ovmf-vars.fd) - OVMFPopulateSecureBoot can add certificates to
       the ovmf-vars firmware.
     * certs - NewEFISignatureDatabase
     * shim - VendorDBSectionWrite , SetVendorDB
     * stubby - Smoosh

   The functionality is exposed bkcust cli mentioned above.

What is still todo:

  * create an initramfs api that allows you to easily combine initramfs
  * restore working oci-boot command. it probably needs adjusting given the
    changes.  From a bootkit layer, it appears to only use 'kernel.efi',
    optionally shim.efi and modules.squashfs.  So it might make more sense
    to just have the user point at those things.
  * add tests more, call tests from c-i
@smoser smoser marked this pull request as ready for review August 18, 2023 15:37
@hallyn hallyn merged commit 14a2a0d into project-machine:main Aug 18, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@smoser @hallyn