rhboot/dbxtool

Tool for UEFI Secure Boot DBX updates

dbxtool's Issues

Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument

I'm experiencing this bug on two computers:
[ 0.000000] DMI: /NUC5PPYB, BIOS PYBSWCEL.86A.0074.2018.0709.1332 07/09/2018
[ 0.000000] DMI: HP HP Spectre Notebook/81A0, BIOS F.41 06/15/2018

Both run Fedora 29, and have dbxtool-8-7.fc29.x86_64, and kernel 4.19.2-300.fc29.x86_64.

From the NUC journal (same as on the HP):

Nov 20 12:12:18 fnuc.local audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbxtool comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 20 12:12:18 fnuc.local dbxtool[656]: Applying 1 updates
Nov 20 12:12:18 fnuc.local dbxtool[656]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Nov 20 12:12:18 fnuc.local dbxtool[656]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument
Nov 20 12:12:18 fnuc.local dbxtool[656]: Cannot Continue.: Invalid argument
Nov 20 12:12:20 fnuc.local systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Nov 20 12:12:20 fnuc.local systemd[1]: dbxtool.service: Failed with result 'exit-code'.
Nov 20 12:12:20 fnuc.local audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbxtool comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

And then run

[root@fnuc ~]# /usr/bin/dbxtool -a /usr/share/dbxtool/ -v
Getting next EFI_SIGNATURE_DATA
Getting next ESL buffer
Getting next EFI_SIGNATURE_DATA
Getting next EFI_SIGNATURE_LIST
Attempting to identify filetype: va2 guid is {pkcs7_cert} 
guid table guid is {pkcs7_cert}
ft_append_timestamp is 2010-03-06 19:17:21
Attempting to apply 1 updates
Sorting updates list
Checking if "DBXUpdate-2016-08-09-13-16-00.bin" has been applied.
Getting next EFI_SIGNATURE_DATA
Getting next ESL buffer
Update entry is not applied.
Update "DBXUpdate-2016-08-09-13-16-00.bin" is not applied
Applying 1 updates
Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument
Cannot Continue.: Invalid argument
error trace:
 efivarfs.c:363 efivarfs_set_variable(): write failed: Bad file descriptor
 efivarfs.c:388 efivarfs_append_variable(): efivarfs_set_variable failed: Invalid argument
 lib.c:113 efi_append_variable(): ops->append_variable() failed: Invalid argument
[root@fnuc ~]# 

Downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1593258

8: missing git version tag

Looks like in git repo is missing version tag for version 8.

BTW: do you have any plans to make next release? (just flush current changes)

Use a heuristic to auto-apply dbx updates

At the moment dbxtool.service unconditionally applies dbx updates in /usr/share/dbxtool which is suboptimal when people have installed versions of shim/grub which will not boot with the updated dbx table.

My proposal would be something like this:

• Ship the new updated dbx update in this repo, and install it to /usr/share/dbxtool like the other update.
• Add a --check-certs argument to the dbxtool.service
• Add a check_certs argument to dbxtool CLI, which checks the certificate timestamp of the installed shim (and grub?) on the ESP
• Add some metadata to the installed files (perhaps something like /usr/share/dbxtool/xmls/DBXUpdate-2016-08-09-13-16-00.xml) which specifies the minimum certificate timestamp required to auto-apply the dbx update -- XML/JSON/TXT format irrelevant. I don't think a "checksum allow-list" scales but it's another simpler idea.

Some comments:

• If the check-shim heuristic fails, the user can apply the dbx update manually, just by missing out the --check-shim argument or maybe a --force argument instead
• We don't really care about non-FAT32 ESPs or multiple-ESPs
• We need to log a warning in the journal if the update service fails due to the ESP check somewhere the admin will see
• We'd need to grow a OpenSLL dep in dbxtool to read the certificate signature timestamps I think
• We need to fail the --check-certs argument if running on a LiveCD media as the ESP won't be the system ESP.

Signature List is malformed

The dbxtool service fail to start with the message "EFI Signature List is malformed"

---

$ systemctl status dbxtool 

● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-11-01 10:46:53 -02; 5h 11min ago
  Process: 1276 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 1276 (code=exited, status=1/FAILURE)

Nov 01 10:46:53 inspiron7000 dbxtool[1276]: dbxtool: EFI Signature List is malformed
Nov 01 10:46:53 inspiron7000 dbxtool[1276]: dbxtool: list has 2343 bytes left, element is 1691 bytes
Nov 01 10:46:52 inspiron7000 systemd[1]: Started Secure Boot DBX (blacklist) updater.
Nov 01 10:46:53 inspiron7000 systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Nov 01 10:46:53 inspiron7000 systemd[1]: dbxtool.service: Unit entered failed state.
Nov 01 10:46:53 inspiron7000 systemd[1]: dbxtool.service: Failed with result 'exit-code'.

---

System information
Fedora 27
Package version: dbxtool-8-3.fc27.x86_64

@vathpela , if you need more information, let me know.
RH_Bugzilla: 1489942

Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin"

This is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1516599#c4

It happens on an Intel NUC
[ 0.000000] DMI: /NUC5PPYB, BIOS PYBSWCEL.86A.0063.2017.0807.1503 08/07/2017

with

# rpm -q dbxtool
dbxtool-8-3.fc27.x86_64

vars.tar.gz