Bug 1658814

+++ This bug was initially created as a clone of Bug #1516599 +++

+++ This bug was initially created as a clone of Bug #1489942 +++

Description of problem:
dbxtool fails at boot 'Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied'


Version-Release number of selected component (if applicable):
dbxtool-7-6.fc27.aarch64

How reproducible:
always

Steps to Reproduce:
1. Install on aarch64 using Fedora-27-20170901.n.1

[root@seattle ~]# systemctl --all --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION                        
● dbxtool.service loaded failed failed Secure Boot DBX (blacklist) updater

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[root@seattle ~]# systemctl status dbxtool.service
● 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 Fri 2017-09-08 13:03:12 EDT; 38min ago
  Process: 665 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ (code=exited, status=1/FAILURE)
 Main PID: 665 (code=exited, status=1/FAILURE)

Sep 08 13:03:12 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Applying 1 updates
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Permission denied
Sep 08 13:03:12 localhost.localdomain dbxtool[665]: Cannot Continue.: Permission denied
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Sep 08 13:03:12 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.


Expected results:
No failed services.

--- Additional comment from Mads Villadsen on 2017-09-16 07:55:18 EDT ---

I'm seeing the same problem on x86 with dbxtool-7-6.fc27.x86_64

--- Additional comment from Dusty Mabe on 2017-10-11 14:11:54 EDT ---

is this a blocker for f27 ? can we submit it as a blocker if it is ?

--- Additional comment from Dusty Mabe on 2017-10-11 14:12:36 EDT ---

FYI we are seeing this in atomic as well: https://pagure.io/atomic-wg/issue/348

--- Additional comment from Dusty Mabe on 2017-10-11 14:27:35 EDT ---

14:25:09    pjones | can you get an strace of it running?
14:25:25 dustymabe | an strace of dbxtool? 
14:25:45    pjones | yeah
14:26:06 dustymabe | i can try 
14:26:10    pjones | probably just "sudo strace -o dbxtool.strace dbxtool -a"

ksinny/pwhalen, can we get that output?

--- Additional comment from Paul Whalen on 2017-10-11 16:16:07 EDT ---

[root@seattle ~]# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin
Applying 1 updates
Applying "/usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Could not apply database update "/usr/share/dbxtool/DBXUpdate-2016-08-09-13-16-00.bin": Permission denied
Cannot Continue.: Permission denied

--- Additional comment from Paul Whalen on 2017-10-11 16:16 EDT ---



--- Additional comment from Peter Jones on 2017-10-17 16:52:40 EDT ---

So, this is really quite perplexing:
> openat(AT_FDCWD, "/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_WRONLY|O_CREAT, 000) = 3
> ioctl(3, FS_IOC_GETFLAGS, 0xfffffd98b104) = 0
> ioctl(3, FS_IOC_SETFLAGS, 0xfffffd98b104) = 0
> write(3, "g\0\0\0\332\7\3\6\23\21\25\0\0\0\0\0\0\0\0\0\21\r\0\0\0\2\361\16\235\322\257J"..., 7089) = -1 EACCES (Permission denied)

That basically says the file isn't there, but we also can't write to it when it's created.  Normally this means Secure Boot is enabled but the Key Exchange Key is a different one than our dbx was created with.  Does the machine have secure boot enabled at all?  Can you attach the results of:

tar cf sb.tar.gz /sys/firmware/efi/efivars/{{PK,KEK}-8be4df61-93ca-11d2-aa0d-00e098032b8c,*-d719b2cb-3d3a-4596-a3bc-dad00e67656f}

--- Additional comment from Dusty Mabe on 2017-10-17 17:53:19 EDT ---

This is actually very easy to reproduce using a UEFI x86_64 VM and an atomic host ISO [1]. Just boot up the VM and run through the anaconda install giving it all the defaults. 

[1] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171017.n.0/compose/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20171017.n.0.iso

I see the same strace output as reported by pwhalen. None of those files that you are asking for exist on my system:

[root@localhost ~]# rpm -q grub2-efi-x64 dbxtool kernel
grub2-efi-x64-2.02-18.fc27.x86_64
dbxtool-7-6.fc27.x86_64
kernel-4.13.5-300.fc27.x86_64
[root@localhost ~]# ls -1 /sys/firmware/efi/efivars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
MTC-eb704011-1402-11d3-8e77-00a0c969723b
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa

--- Additional comment from Dusty Mabe on 2017-10-17 18:07:14 EDT ---

Note this also happens for a UEFI x86_64 VM install using the (non-atomic) Everything netinstall ISO. 

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171017.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-27-20171017.n.0.iso

going to propose this as a blocker for f27.

--- Additional comment from Fedora Blocker Bugs Application on 2017-10-17 18:08:31 EDT ---

Proposed as a Blocker for 27-final by Fedora user dustymabe using the blocker tracking app because:

 systemd unit failure on UEFI x86_64 VMs with a vanilla install.

--- Additional comment from Peter Jones on 2017-10-18 13:39:17 EDT ---

So I think what's going on here is the firmware added the feature that doesn't allow you to create variables in the global namespace that aren't defined in the spec, only they picked "not defined in features we implement" instead of "not defined at all".

--- Additional comment from Fedora Update System on 2017-10-18 13:46:23 EDT ---

dbxtool-8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Adam Williamson on 2017-10-18 15:01:45 EDT ---

The criterion here is "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."

--- Additional comment from Fedora Update System on 2017-10-19 11:23:02 EDT ---

dbxtool-8-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Dusty Mabe on 2017-10-19 12:10:55 EDT ---

dbxtool-8-1.fc27 does not seem to fix the problem for me: 

```
[root@localhost ~]# systemctl status dbxtool.service 
● 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 Thu 2017-10-19 12:06:36 EDT; 2min 41s ago
  Process: 747 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f (code=exited, status=1/FAILURE)
 Main PID: 747 (code=exited, status=1/FAILURE)

Oct 19 12:06:36 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Applying 1 updates
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Invalid argument
Oct 19 12:06:36 localhost.localdomain dbxtool[747]: Cannot Continue.: Invalid argument
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Oct 19 12:06:36 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# rpm -q dbxtool 
dbxtool-8-1.fc27.x86_64
```

--- Additional comment from Dusty Mabe on 2017-10-19 12:41:12 EDT ---

I ran an strace again:

```
# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool                                                                         
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.

```

--- Additional comment from Dusty Mabe on 2017-10-19 12:42 EDT ---



--- Additional comment from Fedora Update System on 2017-10-19 12:54:19 EDT ---

dbxtool-8-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Paul Whalen on 2017-10-19 13:40:52 EDT ---

[root@mustang ~]# rpm -q dbxtool
dbxtool-8-2.fc27.aarch64
[root@mustang ~]# 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-07-12 09:02:23 CDT; 3 months 7 days ago
  Process: 1375 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 1375 (code=exited, status=1/FAILURE)

Jul 12 09:02:22 localhost.localdomain systemd[1]: Started Secure Boot DBX (blacklist) updater.
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Unit entered failed state.
Jul 12 09:02:23 localhost.localdomain systemd[1]: dbxtool.service: Failed with result 'exit-code'.
[root@mustang ~]# strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.

--- Additional comment from Paul Whalen on 2017-10-19 13:42 EDT ---



--- Additional comment from Dusty Mabe on 2017-10-19 13:47:08 EDT ---

fails for me too: 

```
[root@localhost ~]# rpm -q dbxtool 
dbxtool-8-2.fc27.x86_64
[root@localhost ~]# dbxtool -a /usr/share/dbxtool
dbxtool: PK is not set on this system.
dbxtool: KEK is not set on this system.
dbxtool: Not attempting to apply updates.
[root@localhost ~]# echo $?
1
```

--- Additional comment from Adam Williamson on 2017-10-19 20:34:13 EDT ---

If this is aarch64 specific, it cannot possibly be a release blocker, as aarch64 is not a release-blocking arch at present. The release-blocking arches for F27 are armhfp and x86_64.

--- Additional comment from Dusty Mabe on 2017-10-19 21:32:05 EDT ---

(In reply to Adam Williamson from comment #22)
> If this is aarch64 specific, it cannot possibly be a release blocker, as
> aarch64 is not a release-blocking arch at present. The release-blocking
> arches for F27 are armhfp and x86_64.

This is not aarch64 specific. We need to add a "does `systemctl --failed` pass?" test to our Atomic Host ISO tests and our Everything ISO installer test. That would have uncovered these problems.

--- Additional comment from Adam Williamson on 2017-10-20 12:35:33 EDT ---

Oh, OK. We already do such a test in openQA, but from BIOS installs, not UEFI installs.

--- Additional comment from Gleidson Baleeiro on 2017-10-20 17:19:07 EDT ---

The problem persist on x86_64 arch.

$ rpm -qa dbxtool 
dbxtool-8-1.fc27.x86_64


$ /usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f
dbxtool: EFI Signature List is malformed
dbxtool: list has 2343 bytes left, element is 1691 bytes
$ echo $?
1

$ 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 Fri 2017-10-20 18:57:05 -02; 14min ago
  Process: 957 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q -f (code=exited, status=1/FAILURE)
 Main PID: 957 (code=exited, status=1/FAILURE)
      CPU: 11ms

Oct 20 18:57:01 inspiron7000 systemd[1]: Started Secure Boot DBX (blacklist) updater.
Oct 20 18:57:02 inspiron7000 dbxtool[957]: dbxtool: EFI Signature List is malformed
Oct 20 18:57:02 inspiron7000 dbxtool[957]: dbxtool: list has 2343 bytes left, element is 1691 bytes
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Unit entered failed state.
Oct 20 18:57:05 inspiron7000 systemd[1]: dbxtool.service: Failed with result 'exit-code'.

How can i help with this problem ?

--- Additional comment from Adam Williamson on 2017-10-20 17:24:54 EDT ---

Well, for a start can you test with 8-2 rather than 8-1? that's the most recent attempt to fix this. though Dusty and Paul already report that it doesn't work, so my hopes aren't high. Other than that I'm not sure there's a lot you can do, as pjones can probably reproduce the bug quite trivially locally and just has to come up with a fix that actually works...

--- Additional comment from Dusty Mabe on 2017-10-21 10:42:57 EDT ---

(In reply to Adam Williamson from comment #24)
> Oh, OK. We already do such a test in openQA, but from BIOS installs, not
> UEFI installs.

can you add that test to UEFI installs, or can you show me how?

--- Additional comment from Matthew Miller on 2017-10-21 13:32:32 EDT ---

+1 blocker based on the criteria Adam quotes

--- Additional comment from Fedora Update System on 2017-10-21 15:26:18 EDT ---

dbxtool-8-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Gleidson Baleeiro on 2017-10-22 18:30:06 EDT ---

The problem persist with version dbxtool-8-2.fc27.x86_64

● 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 Sun 2017-10-22 19:21:54 -02; 45min ago
  Process: 920 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 920 (code=exited, status=1/FAILURE)
      CPU: 9ms

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

--- Additional comment from Gleidson Baleeiro on 2017-10-22 19:14:52 EDT ---

my system configuration 

           /:-------------:\          gleidson@inspiron7000
        :-------------------::        OS: Fedora 27 TwentySeven
      :-----------/shhOHbmp---:\      Kernel: x86_64 Linux 4.13.8-300.fc27.x86_64
    /-----------omMMMNNNMMD  ---:     Uptime: 1h 53m
   :-----------sMMMMNMNMP.    ---:    Packages: 3304
  :-----------:MMMdP-------    ---\   Shell: zsh 5.4.1
 ,------------:MMMd--------    ---:   Resolution: 3840x1080
 :------------:MMMd-------    .---:   DE: GNOME 
 :----    oNMMMMMMMMMNho     .----:   WM: GNOME Shell
 :--     .+shhhMMMmhhy++   .------/   WM Theme: 
 :-    -------:MMMd--------------:    GTK Theme: Arc [GTK2/3]
 :-   --------/MMMd-------------;     Icon Theme: Papirus
 :-    ------/hMMMy------------:      Font: Cantarell 11
 :-- :dMNdhhdNMMNo------------;       CPU: Intel Core i7-7500U @ 4x 3.5GHz [25.0°C]
 :---:sdNMMMMNds:------------:        GPU: intel
 :------:://:-------------::          RAM: 2367MiB / 15942MiB
 :---------------------://

--- Additional comment from Geoffrey Marr on 2017-10-23 15:30:48 EDT ---

Discussed during the 2017-10-23 blocker review meeting: [1]

The decision to classify this bug as a RejectedBlocker and an AcceptedFreezeException was made on the basis that this bug will not affect all installs and there is no practical consequence to the bug. Fixing this will improve the "polish" of Fedora and can't be accomplished with an update, so it has been accepted as an FE.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-10-23/f27-blocker-review.2017-10-23-16.00.txt

--- Additional comment from Fedora Update System on 2017-10-24 12:45:45 EDT ---

dbxtool-8-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Paul Whalen on 2017-10-24 13:02:36 EDT ---

dbxtool-8-3.fc27 is working with no failure on boot

[root@mustang ~]# systemctl --all --failed
0 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[root@mustang ~]# systemctl status dbxtool
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor pres
   Active: active (exited) since Wed 2017-07-12 10:01:23 EDT; 3 months 12 days a
  Process: 617 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited
 Main PID: 617 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/dbxtool.service

Jul 12 10:01:23 localhost.localdomain systemd[1]: Started Secure Boot DBX (black
[root@mustang ~]# rpm -q dbxtool
dbxtool-8-3.fc27.aarch64

--- Additional comment from Fedora Update System on 2017-10-25 11:22:42 EDT ---

dbxtool-8-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-671a614067

--- Additional comment from Gleidson Baleeiro on 2017-10-25 12:06:58 EDT ---

The initial problem of permission denied was resolved, but at my laptop x86_64 (arch) the problem of comment #30 persist. 

Is it some misconfiguration no my system?

--- Additional comment from Gleidson Baleeiro on 2017-10-25 12:08:36 EDT ---

test of comment #36 was using dbxtool-8-3.fc27.x86_64

--- Additional comment from Adam Williamson on 2017-10-25 12:41:51 EDT ---

gleidson: it looks like you're seeing a system-specific problem that's different from everyone else's:

dbxtool: EFI Signature List is malformed

that sounds like dbxtool thinks something's wrong with the signatures stored in your system's list. It should probably be followed up separately, but I'm not sure a bug report's the right way, as at least on the face of it, dbxtool isn't actually doing anything 'wrong', it's reporting an unexpected and apparently incorrect situation it's found in your system firmware. pjones may have ideas about how to deal with it.

--- Additional comment from Fedora Update System on 2017-10-29 21:52:34 EDT ---

dbxtool-8-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

--- Additional comment from Peter Jones on 2017-10-30 11:31:03 EDT ---

(If you could open an issue about the "Signature List is malformed" thing on https://github.com/rhboot/dbxtool/issues , that would be good.  Please include the command line you used, etc.)

--- Additional comment from Alvin on 2017-11-21 07:25:08 EST ---

dbxtool-8-3.fc27 here:

● 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 Tue 2017-11-21 13:19:18 CET; 3min 40s ago
  Process: 7667 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 7667 (code=exited, status=1/FAILURE)

systemd[1]: Started Secure Boot DBX (blacklist) updater.
dbxtool[7667]: Applying 1 updates
dbxtool[7667]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
dbxtool[7667]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted
dbxtool[7667]: Cannot Continue.: Operation not permitted
systemd[1]: ^[[0;1;39mdbxtool.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: ^[[0;1;39mdbxtool.service: Unit entered failed state.
systemd[1]: ^[[0;1;39mdbxtool.service: Failed with result 'exit-code'.

--- Additional comment from Subhendu Ghosh on 2017-11-22 23:09:29 EST ---

Still seeing the file (no such file or directory ) error

dbxtool-8-3.fc27.x86_64

strace attached

--- Additional comment from Subhendu Ghosh on 2017-11-22 23:12:36 EST ---

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": Operation not permitted
Cannot Continue.: Operation not permitted
error trace:
 efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted
 efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted
 lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted

--- Additional comment from Brendan Weir on 2017-11-25 16:21:23 EST ---

Hello

I'm also getting dbxtool errors on a Lenovo ideapad 510

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

# systemctl status dbxtool.service 
● 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 Sat 2017-11-25 20:55:14 GMT; 23min ago
  Process: 789 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ -q (code=exited, status=1/FAILURE)
 Main PID: 789 (code=exited, status=1/FAILURE)

Nov 25 20:55:09 bwlaptop systemd[1]: Started Secure Boot DBX (blacklist) updater.
Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying 1 updates
Nov 25 20:55:11 bwlaptop dbxtool[789]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
Nov 25 20:55:11 bwlaptop dbxtool[789]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation 
Nov 25 20:55:11 bwlaptop dbxtool[789]: Cannot Continue.: Operation not permitted
Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Unit entered failed state.
Nov 25 20:55:14 bwlaptop systemd[1]: dbxtool.service: Failed with result 'exit-code'.

--- Additional comment from Chris Murphy on 2017-11-26 21:31:03 EST ---

I see this same message on an Intel NUC with current firmware from Intel.
[    0.000000] DMI:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0063.2017.0807.1503 08/07/2017


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

--- Additional comment from Chris Murphy on 2017-11-26 21:34 EST ---

tar cjf vars.tar.bz2 /sys/firmware/efi/efivars/{PK,KEK,db}*

--- Additional comment from Milan J on 2017-11-29 11:13:50 EST ---

I have exactly the same issue as Subhendu Ghosh reported. ThinkPad T440, BIOS version 2.44 (latest).

--- Additional comment from Milan J on 2017-12-01 09:19 EST ---

Attached archive w/ efivars

--- Additional comment from  on 2018-02-09 13:52:06 EST ---

Same 'Operation not permitted' messages on Hewlett-Packard HP Pavilion 15 Notebook.

bash-4.4$ sudo rpm -q dbxtool
dbxtool-8-3.fc27.x86_64

strace -o strace.dbxtool.txt dbxtool -a /usr/share/dbxtool
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": Operation not permitted
Cannot Continue.: Operation not permitted

bash-4.4$ ls /sys/firmware/efi/efivars/ | grep dbx
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c

--- Additional comment from Will Thompson on 2018-02-14 16:20:49 EST ---

I see this failure, too, on a Dell XPS 13 9343 with BIOS version A14. Secure Boot is disabled.

% rpm -q dbxtool
dbxtool-8-3.fc27.x86_64
% sudo /usr/bin/dbxtool -a /usr/share/dbxtool/ --verbose 
[...]
Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted
Cannot Continue.: Operation not permitted
error trace:
 efivarfs.c:319 efivarfs_set_variable(): open(/sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f, O_WRONLY|O_CREAT, mode) failed: Operation not permitted
 efivarfs.c:361 efivarfs_append_variable(): efivarfs_set_variable failed: Operation not permitted
 lib.c:113 efi_append_variable(): ops->append_variable() failed: Operation not permitted

I did notice a page in the firmware under Secure Boot named Expert Key Management. It contained a checkbox, disabled by default, "Enable Custom Mode", with UI elements to manipulate PK/KEK/db/dbx. The help text explained:

> Expert Key Management allows the PK, KEK, db and dbx security key databases
> to be manipulated. The keys can only be modified if the system is in Custom
> Mode. If Custom mode is disabled, any changes made while in Custom Mode will
> be erased and the keys will revert back to their default setting.
> [Documentation about the buttons in this UI to manipulate each database
> elided.]

Enabling this checkbox sounded promising but sadly had absolutely no effect on opening dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f for write.

--- Additional comment from Andrej Podzimek on 2018-04-06 20:45:14 EDT ---

Same problem on Dell Inspiron 7548/0AM6R0. Also on Fedora 28 with dbxtool-8-4.fc28.x86_64:

systemd[1]: Started Secure Boot DBX (blacklist) updater.
dbxtool[10106]: Applying 1 updates
dbxtool[10106]: Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21
dbxtool[10106]: Could not apply database update "DBXUpdate-2016-08-09-13-16-00.bin": Operation not permitted
dbxtool[10106]: Cannot Continue.: Operation not permitted

BTW, this bug looks just about the same as https://bugzilla.redhat.com/show_bug.cgi?id=1489942

--- Additional comment from Bob Hockney on 2018-05-06 11:09:52 EDT ---

Seeing the same issue on a Zotac Ci327 Nano; Fedora 27 installed, x86_64

Secure boot enable
Same messages as comment 10.

--- Additional comment from Laszlo Ersek on 2018-05-15 19:42:27 EDT ---

The "Operation not permitted" error occurs because efivarfs_set_variable() [src/efivarfs.c] calls open() in not-read-only-mode *before* it calls efivarfs_set_fd_immutable(..., 0). (Looking at upstream efivar @ 9896c26c7e68.) That won't work; the kernel sets the dbx-... pseudo-file to immutable by default, and that can only be cleared by opening the file for r/o first, and calling the ioctl(). The open for write can come only after.

A similar issue was corrected earlier in upstream efivar commit 4c20a6de.

This issue can be worked around by running "chattr -i" on the dbx-... file manually, before invoking dbxtool.


I see another issue in efivarfs_set_variable():

	if (attributes & EFI_VARIABLE_APPEND_WRITE) {
		flags = O_APPEND|O_CREAT;
		flagstr = "O_APPEND|O_CREAT";
	} else {

technically this might work on Linux, but really one of O_RDWR or O_WRONLY should be present too.

--- Additional comment from Laszlo Ersek on 2018-05-16 19:02 EDT ---

Attaching the patch that fixes efivarfs_set_variable(). The patch applies to the upstream efivar tag called "32", hence it is suitable for Fedora 27:

- scratch build: efivar-32-2.bz1516599.fc27
  https://koji.fedoraproject.org/koji/taskinfo?taskID=27001571

I tested this on OVMF, together with the dbxtool fix (from bug 1508808 comment 25). The dbxtool systemd service now works fine without errors or workarounds. I tested two scenarios:
- when "dbx" didn't exist on boot (but SB was otherwise enabled),
- when "dbx" existed with a single sha256 entry.

NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned.

--- Additional comment from Laszlo Ersek on 2018-05-16 19:06 EDT ---

Attaching the patch that fixes efivarfs_set_variable(). The patch applies to current upstream efivar (master @ commit 9896c26c7e68), hence it is suitable for Fedora 28:

- scratch build: efivar-35-1.bz1516599.fc28
  https://koji.fedoraproject.org/koji/taskinfo?taskID=27001318

NOTE: if you try this and it bricks your device, I take no responsibility. You have been warned.

--- Additional comment from Subhendu Ghosh on 2018-05-16 22:27:54 EDT ---

Laszlo -- Thanks for the workaround + patch - will give it a try once it hits the testing repo.

--- Additional comment from Chris Murphy on 2018-07-19 13:01:47 EDT ---

I still see this on an Intel NUC with current firmware and

efivar-35-1.fc28.x86_64
dbxtool-8-5.fc28.x86_64

--- Additional comment from Mike Gerber on 2018-08-15 07:12:40 EDT ---

Removing the immutable flag worked for me (Thinkpad X230):

# chattr -i /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f 
# /usr/bin/dbxtool -a /usr/share/dbxtool/ -q
Applying 1 updates
Applying "DBXUpdate-2016-08-09-13-16-00.bin" 2010-3-6 19:17:21


After that, I get a possibly unrelated error:

# /usr/bin/dbxtool -a /usr/share/dbxtool/ -q
dbxtool: EFI Signature List is malformed
dbxtool: list has 3800 bytes left, element is 76 bytes
# echo $?
1

--- Additional comment from Laszlo Ersek on 2018-08-15 11:07:59 EDT ---

Upstream efivar now contains the patch from comment 14, as commit 9c51123abebd.

--- Additional comment from Ben Cotton on 2018-11-27 09:47:02 EST ---

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Ben Cotton on 2018-11-30 17:24:39 EST ---

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--- Additional comment from Laszlo Ersek on 2018-12-03 06:04:52 EST ---

Reopening for Fedora 28.

- According to comment 18, the upstream fix is commit 9c51123abebd. The first upstream tag that said commit is part of is "36".

- Checking the "efivar" package in Koji: <https://koji.fedoraproject.org/koji/packageinfo?packageID=17225>, the latest build for Fedora 28 is "efivar-35-1.fc28" <https://koji.fedoraproject.org/koji/buildinfo?buildID=1067810>. It is based on upstream tag "35", and the %changelog does not mention a backport of upstream commit 9c51123abebd. (In fact, the package is dated 2018-Apr-09, while the upstream fix was applied on 2018-May-17.)

--- Additional comment from Laszlo Ersek on 2018-12-11 05:42:39 EST ---

This should be fixed in the most recent build:

  efivar-37-1.fc28
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1169369

--- Additional comment from Chris Murphy on 2018-12-11 18:55:22 EST ---

Any idea why efivar-37-1 isn't listed in Bodhi? It's not in updates-testing for either Fedora 28 or 29.
https://bodhi.fedoraproject.org/updates/?packages=efivar

--- Additional comment from Laszlo Ersek on 2018-12-12 04:58:06 EST ---

Chris, thanks for raising this question. In fact when I made comment 22 yesterday, I intended to provide a direct Bodhi link as well. However...

(1) Not sure when exactly it must have happened, but the Bodhi WebUI has semi(?)recently regressed to the point where it's now borderline unusable, in my opinion anyway. For about ten minutes I couldn't decide whether the reason for my not finding a Bodhi update for efivar was my lacking Bodhi-fu, or the actual absence of a Bodhi update. Consider, for example <https://bodhi.fedoraproject.org/updates/?releases=F28&status=testing>. It currently gives you a list of 325 package updates, broken down into 17 pages of 20 updates each. There is no way to search for a package by name, or to increase the update count per page (after which one could use the browser's in-page search function). Am I *really* supposed to click through 17 pages to find the update I'm looking for?

(2) Ultimately, I somehow stumbled upon Peter's page at <https://bodhi.fedoraproject.org/users/pjones>. That's a lot more focused view, and I didn't see an update there. So I *guess* that the Bodhi update is not there because Peter has yet to submit it.

--- Additional comment from Adam Williamson on 2018-12-12 14:01:07 EST ---

If you're searching for an update by package name, just...search. There's a magnifying glass at top-right of the web UI. That's the search button. Click it, type the package name.

Maybe it could be a bit more prominent, it is a bit small and grey and out of the way. Really it's probably the most common 'entry point' for doing stuff with Bodhi from the front page, I'd think (that and the 'profile' page, I guess).

--- Additional comment from Laszlo Ersek on 2018-12-12 14:32:08 EST ---

Hi Adam, thanks for the hint. In the upper right corner of <https://bodhi.fedoraproject.org/>, I don't see a magnifying glass. Instead, I see the number "14", in digital clock script: <https://imgur.com/a/SYe76GH>.

--- Additional comment from Adam Williamson on 2018-12-12 14:37:36 EST ---

That's...not normal. I see the search icon whether I'm logged in or out. Are you blocking scripts or CSS, perhaps? Or forcing fonts? Does it actually work for searching when you click on it, regardless of what it looks like?

--- Additional comment from Laszlo Ersek on 2018-12-12 14:41:41 EST ---

If I set "Allow pages to choose their own fonts, instead of my selections above" in Firefox, then the magnifying glass appears. However, I didn't randomly clear that checkbox. I need to enforce a minimum font size, and I depend on fonts to look mostly uniform.

Bodhi's use of a custom font for the magnifying glass / search link is *wrong*. For starters, it is inconsistent with the rest of the landing page. The "Stats" and "Login" widgets are in normal Latin script, why can't "Search" be the same? Furthermore, the small icons all over the table (Security updates / Bugfix updates / Enhancement updates / New package updates) look like normal images to me. If "Search" has to be a magnifying glass and not Latin script, why can't it be a similar picture?

--- Additional comment from Laszlo Ersek on 2018-12-12 14:43:24 EST ---

Anyway, yes, if I click "14", the search function works fine. Thank you!

--- Additional comment from Randy Barlow on 2018-12-12 14:52:52 EST ---

There is a ticket about making the search more obvious in the UI: https://github.com/fedora-infra/bodhi/issues/1455

--- Additional comment from Laszlo Ersek on 2018-12-12 16:33:31 EST ---

Thank you Randy, I've now pinged that ticket.

--- Additional comment from Adam Williamson on 2018-12-12 16:38:50 EST ---

Using some kind of image font is pretty standard practice on Teh Intarwebz these days. I gave up trying to force font selection because of this a couple of years back. I just use text zoom for pages that use stupidly tiny fonts now :/

--- Additional comment from Fedora Update System on 2018-12-12 16:54:11 EST ---

efivar-37-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9963fc558e