sbkeysync fails with 'Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting' with 14.04 ovmf

Bug #1274749 reported by Jamie Strandboge on 2014-01-30
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sbsigntool (Ubuntu)
Undecided
Unassigned

Bug Description

Due to bug #1274376 I installed Ubuntu 13.10 in a VM with ovmf 0~20121205.edae8d2d-1, shutdown the vm and then upgraded ovmf to 0~20131029.2f34e065-1 since I found that after repeated reboots when using 0~20121205.edae8d2d-1 ovmf had trouble finding the disk (I don't know why-- I couldn't find a simple reproducer).

So, when using ovmf 0~20131029.2f34e065-1 if I try to install secure boot keys as per the instructions in https://wiki.ubuntu.com/SecurityTeam/SecureBoot#Shim_bootloader_signed_with_Microsoft_key, sbkeysync fails. Eg:

$ sbkeysync --verbose --pk --dry-run
Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting

I used the sb-setup command as per https://wiki.ubuntu.com/SecurityTeam/SecureBoot#Shim_bootloader_signed_with_Microsoft_key:

$ cd /tmp
$ ./sb-setup enroll microsoft
Creating keystore...
  mkdir '/etc/secureboot/keys'
  mkdir '/etc/secureboot/keys/PK'
  mkdir '/etc/secureboot/keys/KEK'
  mkdir '/etc/secureboot/keys/db'
  mkdir '/etc/secureboot/keys/dbx'
done

Creating keys... done

Generating key updates for PK...
  using GUID=f2a7fbab-1471-40da-b18f-6a489d898f91
  creating EFI_SIGNATURE_LIST (test-cert.der.siglist)...
  creating signed update (test-cert.der.siglist.PK.signed)...
done
Generating key updates for KEK...
  using GUID=f2a7fbab-1471-40da-b18f-6a489d898f91
  creating EFI_SIGNATURE_LIST (test-cert.der.siglist)...
  creating signed update (test-cert.der.siglist.KEK.signed)...
done
Generating key updates for KEK...
  using GUID=ed200091-fb45-4da2-8efe-9ce0add35ad4
  creating EFI_SIGNATURE_LIST (microsoft-kekca-public.der.siglist)...
  creating signed update (microsoft-kekca-public.der.siglist.KEK.signed)...
done
Generating key updates for db...
  using GUID=f44c37d2-9123-4b09-abf8-d7fdfdf73476
  creating EFI_SIGNATURE_LIST (microsoft-pca-public.der.siglist)...
  creating signed update (microsoft-pca-public.der.siglist.db.signed)...
done
Generating key updates for db...
  using GUID=97ff929d-201f-44ef-8514-385958672418
  creating EFI_SIGNATURE_LIST (microsoft-uefica-public.der.siglist)...
  creating signed update (microsoft-uefica-public.der.siglist.db.signed)...
done
Initializing keystore...
  adding to /etc/secureboot/keys/PK/
  adding to /etc/secureboot/keys/KEK/
  adding to /etc/secureboot/keys/db/
done

Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting
Commit to keystore? (y|N) n
$

summary: sbkeysync fails with 'Can't access efivars filesystem at
- /sys/firmware/efi/efivars, aborting'
+ /sys/firmware/efi/efivars, aborting' with 14.04 ovmf
description: updated
Steve Langasek (vorlon) wrote :

Yes, this certainly looks like it could be related to bug #1274376, which is a kernel oops in the efivarfs code.

Jamie Strandboge (jdstrand) wrote :

Hmmm, in an effort to get a working secure boot install with ovmf, I install with 13.10 ovmf, shutdown, booted with 14.04 ovmf and did various upgrades, etc, then shutdown. Then I boot with 13.10 ovmf and ran:
$ sudo grub-install --uefi-secure-boot

which succeeded. Then I rebooted with 13.10 ovmf and ran 'sb-setup' as above, and still had the same error:
sbkeysync --verbose --pk --dry-run
Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting

Jamie Strandboge (jdstrand) wrote :

Ok, I just now booted with bios.bin from http://people.canonical.com/~jamie/ovmf/ that I built when first using OVMF with quantal and have the same results as in comment #2. My thinking is that something must have changed incompatibly with newer kernels.

On Tue, Apr 15, 2014 at 01:57:17PM -0000, Adam Conrad wrote:
> Is this a duplicate of
> https://bugs.launchpad.net/ubuntu/+source/sbsigntool/+bug/1257305 ?

No. That bug was closed before this one was opened, and the behavior change
Jamie saw was tied to ovmf versions which 1257305 was not.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers