1. Jul 31, 2021
  2. Nov 17, 2017
    • Patrick Ohly's avatar
      uefi-comboapp.bbclass: install files under pseudo · 5adbf6df
      Patrick Ohly authored
      
      do_uefiapp_deploy copies files into the /boot directory of the rootfs
      and thus, like do_rootfs, should run under pseudo so that the files
      end up being owned by root.
      
      This did not trigger the uid leak check, perhaps because the task runs
      later.
      
      For some (still unknown reason), sometimes the installed files did end
      up being owned by root, which tripped up a swupd test because the
      system update randomly included unexpected changes to bootx64.efi or
      rmc.db. With this change, they are owned by root consistently.
      
      Signed-off-by: default avatarPatrick Ohly <patrick.ohly@intel.com>
      Signed-off-by: default avatarSaul Wold <sgw@linux.intel.com>
      5adbf6df
  3. Jul 19, 2017
    • California Sullivan's avatar
      uefi-comboapp.bbclass: Split signing functionality into its own bbclass · 625a588f
      California Sullivan authored
      
      In the future more secure boot implementations will be offered, with
      each one needing the signing method. Instead of repeating a forty line
      block of code across several recipes, just use a configurable bbclass.
      
      Signed-off-by: default avatarCalifornia Sullivan <california.l.sullivan@intel.com>
      Signed-off-by: default avatarSaul Wold <sgw@linux.intel.com>
      625a588f
    • Patrick Ohly's avatar
      uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes · 21086869
      Patrick Ohly authored
      
      The original code in intel-iot-refkit allows to create more than one
      UEFI combo app and uses that to create one for removable media and one
      for fixed media (after installation), with different boot=PARTUUID=xxx
      parameters. This way, an installed image never ended up booting from
      the install media.
      
      uefi-comboapp.bbclass now supports the same feature, with
      create_uefiapp() as the API function that can be used to create
      additional UEFI apps and create_uefiapps as the method where the call
      can be added.
      
      In addition, several shortcomings are getting addressed:
      - A UEFI combo app must be stored under a name that is specific
        to the image for which it gets created, otherwise different
        image recipes end up overwriting (or using) files from other
        images.
      - Signing must be done after creating the apps and before deploying
        them, otherwise the unsigned apps get copied to the image when
        using do_uefiapp_deploy.
      - The common code for deployment is now in uefiapp_deploy_at.
      - $dest is used instead of ${DEST} because the latter might get
        expanded by bitbake.
      - Because do_uefiapp always had to run anew to produce the
        clean, unsigned input for do_uefiapp_sign, having two different
        tasks just added unnecessary complexity. Now all code is in
        do_uefiapp.
      - Old files matching the output pattern get removed explicitly,
        because they might not get overwritten when the optional
        app suffix changes between builds, or when the task fails
        in the middle.
      
      Signed-off-by: default avatarPatrick Ohly <patrick.ohly@intel.com>
      Signed-off-by: default avatarSaul Wold <sgw@linux.intel.com>
      21086869
  4. Jul 10, 2017