Commit Graph

5 Commits

Author SHA1 Message Date
Anuj Mittal
0584f63879 Convert to new override syntax
Use the convert-overrides.py to convert to new syntax and manually
fix some additional changes.

Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
2021-07-31 17:47:03 +08:00
Patrick Ohly
5adbf6df4f uefi-comboapp.bbclass: install files under pseudo
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: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
2017-11-17 10:54:21 -08:00
California Sullivan
625a588f70 uefi-comboapp.bbclass: Split signing functionality into its own bbclass
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: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
2017-07-19 08:30:08 -07:00
Patrick Ohly
21086869be uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes
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: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
2017-07-19 08:30:08 -07:00
California Sullivan
8b022e4a9c classes: Add uefi-comboapp bbclass
This bbclass pulls in the portion of code that builds a UEFI combo
application from meta-refkit to meta-intel. The combo app contains an
EFI stub from systemd, which allows you to boot a kernel directly, a
kernel, an initramfs, and a command line.

This class is compatible as either an EFI_PROVIDER or IMAGE_CLASSES
target, and does not include the entire _dsk type image creation seen in
meta-refkit.

Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
2017-07-10 12:08:20 -07:00