[Bug 1791222] Re: efivar -a doesn't work, cannot be used to update SecureBoot variables

[Steve Langasek]

While it's true that this makes efivar -a non-functional, we have other
tools in main (sbkeysync from sbsigntool) which can be used to do these
SecureBoot db updates, so while an SRU is justified I'm not planning to
do one at this time.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to efivar in Ubuntu.
https://bugs.launchpad.net/bugs/1791222

Title:
  efivar -a doesn't work, cannot be used to update SecureBoot variables

Status in efivar package in Ubuntu:
  New

Bug description:
  [SRU Justification]
  When using append mode, libefivar's efivarfs_set_variable() opens the target file with flags O_APPEND|O_CREAT, which fails to actually define a read/write mode and therefore the file is opened read-only.  This makes it impossible to use efivar to append to variables, which is the only way to update SecureBoot databases.

  [Test case]
  1. wget -q http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
  2. unzip dbxupdate.zip
  3. sudo apt install efivar
  4. sudo chattr -i /sys/firmware/efi/efivars/dbx-*
  5. sudo efivar -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -a -f /tmp/dbxupdate.bin
  6. Confirm that this fails with 'efivar: Invalid argument'.
  7. Install efivar and libefivar1 from -proposed
  8. Repeat step 5
  9. Confirm that this command exits non-zero
  10. Confirm that 'mokutil --dbx' shows a significant number of revoked hashes.

  [Regression potential]
  Since this function has clearly never ever worked, the only regression potential is if someone somewhere is calling this function with a payload that /shouldn't/ be written to nvram, and as a result of fixing this bug they now have junk written in an EFI variable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/efivar/+bug/1791222/+subscriptions