vathpela / efitools Goto Github PK

I'm trying to push efitools to Fedora repositories. Got some notes during my review:

efitools.x86_64: E: call-to-mktemp /usr/bin/efi-readvar
efitools.x86_64: E: call-to-mktemp /usr/bin/efi-updatevar
should be reported to upstream.

I hope this can be fixed.

sign-efi-sig-list k PK.key -c PK.crt PK PK.esl PK.auth followed by efi-update-var -f PK.auth PK writes fine, but when I try to use the detached signature method, I get Cannot write to PK, wrong filesystem permissions. I have date formatted as 2020-06-26 08:19:12, run sign-efi-sig-list -t "$DATE" -o PK PK.esl PK.forsig, run openssl smime -noattr -sign -binary -in PK.forsig -text -out PK.signed -signer PK.crt -inkey PK.key -outform DER -md sha256 followed by sign-efi-sig-list -i PK.signed -t "$DATE" PK PK.esl PK.auth.

We use efi-readvar in a late-command in Ubuntu's subiquity install system, and recently observed the following.

The installer arrives at it's late-commands stage with a dangling loopback mount to the install media, in turn breaking efi-readvar.

This is safely reproducible on any EFI system:

# mkdir -p /cdrom
# cp /usr/lib/memtest86+/memtest86+.iso /tmp/cdrom.iso
# mount -o loop,ro /tmp/cdrom.iso /cdrom
# rm /tmp/cdrom.iso
# mount -l | grep iso9660
/tmp/cdrom.iso (deleted) on /cdrom type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8) [MT531]

In the output of mount at this stage of the subiquity installer, efivarfs appears behind the /cdrom entry, reproducible as follows:

# umount /sys/firmware/efi/efivars; mount -t efivarfs none /sys/firmware/efi/efivars
# mount -l | egrep '(iso9660|efivarfs)'
/tmp/cdrom.iso (deleted) on /cdrom type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8) [MT531]
none on /sys/firmware/efi/efivars type efivarfs (rw,relatime)

The sscanf() operation in kernel_efivars.c relies on non-whitespace device and mountpoint strings and fails now.

# efi-readvar -v db
No efivarfs filesystem is mounted

I'm not much of a C guy, but I believe the entire iterator around sscanf() loses alignment to line boundaries once %*s has mis-matched the start of the line: https://github.com/vathpela/efitools/blob/master/lib/kernel_efivars.c#L69

Reproduction for whitespace in device name (without the dangling loopback effect):

# cp /usr/lib/memtest86+/memtest86+.iso "/tmp/cdrom image.iso"
# mount -o loop,ro "/tmp/cdrom image.iso" /cdrom
# umount /sys/firmware/efi/efivars; mount -t efivarfs none /sys/firmware/efi/efivars
# efi-readvar -v db
No efivarfs filesystem is mounted

And with whitespace in mountpoint:

# mkdir "/tmp/cdrom loopback"
# mount -o loop,ro /usr/lib/memtest86+/memtest86+.iso "/tmp/cdrom loopback"
# umount /sys/firmware/efi/efivars; mount -t efivarfs none /sys/firmware/efi/efivars
# efi-readvar -v db
No efivarfs filesystem is mounted

I'd be willing to agree that whitespace in device or mountpoint is not best practice system adminstration, however the (deleted) comment on the device file name seems to be a reasonably valid use case beyond individual control.

We've locally worked around this by explicitly umounting the missing cdrom image in subiquity late-commands:

  late-commands:
  	...
    - curtin in-target --target=/target -- umount /cdrom || true
	...

Hi,

Would it be possible to hardwire a network location and have the PreLoader look for the chain file via http or tftp?

It works fine from a bootable cd or usb with an actual esp partition but fails when loading directly over pxe.

The preloader always returns a file not found error when executed over pxe looking for the chain file even when it exists.

usb\cd : shim(signed by microsoft) -> preloader(mok key added to db)-> chained file(ipxe\grub) -> works

pxe: shim(signed by microsoft) -> preloader(mok key added to db) -> chained file(ipxe\grub) -> not working: unable to find and load chain file

shim(signed by microsoft) -> self signed chained file(ipxe\grub) (mok key added to db) -> chain file properly loads but is unable to boot anything even official trusted efi binaries signed by microsoft\fedora\ubuntu etc that are known to work : security protocol fails, invalid parameter errors which is why the preloader is needed

build failed

and the log is：

LockDown.c:44:10: error: ‘KEK_auth_len’ undeclared (first use in this function); did you mean ‘DB_auth_len’?

/usr/bin/cert-to-efi-sig-list

The above is from,
efitools-1.9.2-1.

For secure boot of machine, it is necessary to load the EFI dbs i.e. PK, KEK and allowed database.
For loading PK for example, first the cert needs to be converted into esl
#cert-to-efi-sig-list -g "$(uuidgen)" PK.crt PK.esl

and then self sign in case of PK.
#sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth

and update PK db later with,
#efi-updatevar -f PK.auth PK

So, in this case second step i.e. sign-efi-sig-list needs private key in plain text format.

But if the key has to be retrieved from TPM, in that case it shall be retrieved as encrypted key.

Does efitools support reading key from TPM? Was there any such request? can that enhancement be done?

For secure boot the below page can be referred for more infromation.
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot