Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> custom ways of doing things, instead of furthering efforts like UEFI on ARM.

I thought uBoot was more or less the standard way of booting embedded Linux? Is it really worth bringing the entire UEFI environment, which is basically a mini OS, to such devices? Embedded devices are often designed to handle power loss or even be unplugged by users, so the boot up process is generally as lean as possible.

 help



U-Boot nowadays speaks UEFI :) (and so does LK)

New Android devices all use a UEFI bootloader: https://source.android.com/docs/core/architecture/bootloader...


SecureBoot might be more useful than UEFI on SBC like Pi.

The grub EFI shim is signed, but does or doesn't verify kernel image and initrd and module (and IDK optionally drive and CPU and RAM hw) signatures?

mokutil does module signature key enrollment. Kernel modules must be signed with a key enrolled in the BIOS otherwise they won't be loaded.

To implement SecureBoot without UEFI would be to develop an alternate bootloader verification system.

But what does grub or uboot or p-boot do after the signed grub shim is verified?


mokutil and these commands don't work without UEFI:

  mokutil --sb-state
  mokutil --help
  mokutil --import key.der
  mokutil --list-new
  reboot

  efibootmgr
  efivar

  fwupd
  fwupdtool
  fwupdmgr get-updates && \
  fwupdmgr update

  tree /sys/firmware/efi

  systemctl reboot --firmware-setup

Note that UEFI doesn't mean supporting most of those.

UEFI without runtime UEFI variable writes is a thing, and that configuration is incompatible with mokutil.


FWIU,

There is no SecureBoot without UEFI.

UEFI without SecureBoot does have advantages over legacy BIOS with DOS MBR.

> UEFI without runtime UEFI variable writes is a thing

Which vendors already support this?

Do any BIOS - e.g. coreboot - support disabling online writes to EFI? (with e.g. efibootmgr or efivar or /sys/firmware/efi)

One of the initial use cases for SecureBoot is preventing MBR malware.

What there be security value to addding checksums or signatures as args to each boot entry in grub.cfg for each kernel image and initial ramdrive?

Unless /boot is encrypted, it's possible for malware to overwrite grub.cfg to just omit signatures for example.


> Which vendors already support this?

One implementation I've seen in the wild is: https://docs.nvidia.com/jetson/archives/r36.4/DeveloperGuide...

Secure Boot is still supported in that configuration, but with PK/db/dbx being part of the firmware configuration and updating them requiring a UEFI capsule update.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: