Question: how to identify vendor firmware setups conflicting with disk partitions?

Steve McIntyre steve.mcintyre at linaro.org
Thu Feb 28 17:12:25 UTC 2019


Hi folks,

I've just been having a discussion with folks about installing Debian
on an arm64 device. Another developer is booting via U-Boot with UEFI
and things are working OK, except...

The intructions for their board [0] include writing things raw to both
sector 0 and sector 1 of an SD card, meaning that both MBR and GPT
partitioning schemes are likely to break. Ugh. :-/

So, I have two (related) worries:

 1. At the moment in Debian, our installer will default to using GPT
    for arm64 machines (where disks are not already formatted). That
    was fine when we were expecting server systems booting using edk2,
    but it looks like that's now a dangerous assumption, as more and
    more U-Boot devices are out there which will be wanting to load
    firmware from low-numbered LBAs.

 2. I'm just in the middle of adding EFI armhf installer support, and
    that is also (currently) defaulting to GPT if you've booted via
    EFI. This is fine for VMs booted using a 32-bit Arm build of edk2,
    but also it's starting to look like a bad option for real boards
    booting using U-Boot's EFI support (for similar reasons).

The "Firmware Storage" section of EBBR v0.6 touches on this and
describes how to store firmware in a safer manner, but obviously
(some/many) vendors are not following the spec thus far. What are
other folks doing in this area? How do you recognise which devices
it's safe to use GPT on, for example?

I'm now looking at updating our logic on armhf/arm64 to do something
like:

if (booted via UEFI); then
  if (booted using U-Boot); then
    echo MBR
  else
    echo GPT
  fi
else
  echo MBR
fi

but I'll need to find a sane way to detect U-Boot->UEFI boot. For now
I'm looking at parsing dmesg output to look for something like

[    0.000000] efi: EFI v2.70 by Das U-Boot

but I'm hoping for a better solution. This is also somewhat assuming
that detecting U-Boot in the boot chain is a valid indicator for
"unsafe location for firmware", but I'm not sure of a better way!

[0] http://share.loverpi.com/board/libre-computer-project/libre-computer-board-aml-s905x-cc/u-boot/mainline/README.txt

Cheers,
-- 
Steve McIntyre                                steve.mcintyre at linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs



More information about the boot-architecture mailing list