coreboot EFI working group meeting minutes - 12 October 2021 - coreboot

12 Oct 2021


      # 12 October 2021 - coreboot EFI working group
## Objective:
Linux is expecting more and more to use EFI supplied interfaces (UEFI
Boot Services in particular, even if many are stubbed out) so like it or
not, we’re going to need to support these interfaces. How do we approach
this without turning coreboot into UEFI.
## Decisions:
* The coreboot repo will host an EDK2 fork for use as a coreboot
  payload. Commits to this repo will go through gerrit for review.
* Any code needed to support booting should go into a payload instead of
  coreboot itself.
* We will look at adding chain-loading payload support to coreboot.
  Among other things, this will allow a payload to support turning cbmem
  tables into UEFI HOBs as needed before calling into a UEFI support
  payload.
## Minutes:
* Can you access the VC ? [Chris]
    * 9 people in. Apparently Chrome + Web or using the apps work for
      some people, but not for others.
    * Native [Bluejeans] apps
    * We’ll try a different method for our next meeting - The method
      will be announced after we decide when to hold our next meeting.
* FelixH: this isn’t a job for coreboot.
    * This should definitely be in a payload.
    * If FSP settings need to be configured, this would be a problem.
    * How would we support boot variables?  Or would we?
    * Werner: Agree with keeping this in a payload.
* [pgeorgi] What’s the scope of this project?
    * Just booting?
    * Jay: Syspro is typically asked to create solutions that are NOT
      UEFI.  They want simplicity and boot code to do the minimal
      amount.
    * 9elements: customers are mostly desiring UEFI boot solutions
      * coreboot need additional tables in cbmem to support a better
        UEFI implementation.
* What’s the timeline?
    * When will we NEED to support the EFI interfaces?
    * Do we know what these interfaces will be?
        * Initially just boot services.
* Is there any advantage to pulling EFI into coreboot.
    * No?  Having chainloading payloads could handle any translation
      necessary without tying that to a specific payload. (ie. coreboot
      loads the cbmem2hob payload, which does its thing, then cbmem2hob
      loads the actual payload)
    * Look into chain-loading payloads:  pgeorgi will look into this.
      Proof of concept: move splashscreen support out of ramstage.
* Add an edk2 fork to the coreboot git server
    * Where do we start from?
        * Current EDK2 stable from August 2021.
    * https://review.coreboot.org/edk2.git is now mirrored from
      https://github.com/tianocore/edk2
        * Updated hourly
        * Our own stable tag is default: coreboot-stable202108, based
          off edk2-stable202108
    * How do we pull changes from EDK2
        * Create upstream branch to pull in changes?  The vast majority
          of changes will come into this branch, and someone would need
          to sort them out at some point.
        * What’s the volume of patches that come into the EDK2?  That
          has a big impact to how we address this:
            * About 5 patches a day.
              * checked again: there are ~6000 commits between
                2020-09-20 and 2021-09-20 on edk2/master, so more like
                20 commits a day
        * Can we just create a fork and add things on top, or is there a
          better way to start?
        * Matt currently just creates his fork for the chromebook
          firmwares that he maintains.
    * How do we push changes back to EDK2?
        * This is a big issue - this is why many of the forks were
          created.
        * What’s the volume of our changes that would go into this tree?
    * How do we want to handle commits?
        * Are there enough people to do real code reviews?
        * Let’s just start by pushing through gerrit.
* What other more minimal projects are we interested in pulling in as
  payloads?
    * Yabits, Voodoo, U-Boot’s codebase?
        * Yabits did not work the last time it was (minimally tested)
        * Tianocore is currently not very well featured.
        * There are definitely situations currently where a uefi-payload
          is needed, so if there were something that provided a UEFI
          interface without all of the associated overhead, that would
          be very useful.
        * Everyone has different ideas about what’s needed as a minimal
          solution.
        * Voodoo is trying to get away from running all of this code in
          ring0.
        * No serious discussion about building anything new from scratch
          at this point, but that’s obviously not out of the question if
          someone wanted to start a new project.
* Definitely no one-size fits all solution here
* AI: Need to find out what linux is going to need.
    * Is this just what’s required for grub, or by linux itself - those
      are different things.
    * May be useful to have multiple implementations to find where the
      gaps are.
        * Any maintained implementations are welcome on
          review.coreboot.org! (no graveyard for yabits unless you start
          working on it)
    * Figure out boot services profile for linux as a payload
* AI: look at what grub needs
  * Note that there is "grub as a payload"
* UEFI spec is closed source
    * This would need to be addressed by the UEFI Forum board of
      directors.
    * Nate will pass along the request to make this open source.
* What counts as working?
    * Will definitely set up build testing
    * Can 9elements help any with testing for their purposes at least.
        * 9elements will definitely test, but can’t say at this point
          how it will look.
* Created edk2 repo:
    * Matt to start pushing patches.
    * Martin to set up build testers.
* Discuss whether we need another meeting on the 26th at next week’s
  leadership meeting.
## Agenda & random notes below.
* How do we approach this without turning coreboot into UEFI.  Linux is
  expecting more and more to use EFI supplied interfaces (UEFI Boot
  Services in particular, even if many are stubbed out) so like it or
  not, we’re going to need to support these interfaces.
    * Extend [Yabits]?  This hasn’t had any new commits in over 3 years.
      It also leverages libpayload which is not so much alive either
      these days.
* Through depthcharge, libpayload is probably the most exercised
  payload code you'll find these days that isn't a Linux kernel.
    * Fork EDK2
        * There are already many private forks.  It would be useful to
          have a central location to merge these.  There is a worry
          about who will review the patches.  I don’t think we want
          everyone on the internet to be able to submit and merge
          patches, so we probably want to create a group who can merge
          them.
        * Set up a jenkins builder
        * What codebase do we start with?
    * Extend Ron’s [Voodoo] project
        * This is now passing one of the tests from u-boot efi_selftest
        * Port to arm in progress
    * Write something from scratch
    * Add code to coreboot to create HOB structures and other
      requirements.
        * This was the initial suggestion that was proposed in the
          coreboot meeting last week.
    * Pull in u-boot’s UEFI implementation
* How much of the [UEFI spec] is needed?
    * ARM has a [trimmed down UEFI spec]. Can a similar one be made for
      x86?
    * Boot services
    * Runtime services
    * Secure boot
    * Boot Variables
    * User identification?
    * Apparently EBBR requires mass storage as part of the spec, so more
      a payload matter
[Bluejeans]: https://www.bluejeans.com/downloads
[UEFI spec]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf
[Yabits]: https://github.com/yabits/uefi
[Voodoo]: https://github.com/linuxboot/voodoo
[trimmed down UEFI spec]: https://arm-software.github.io/ebbr/