[Bug 1869792] Re: [MIR] u-boot-rpi

[Dave Jones]

Thanks for the quick response, Seth!

On Sat, Apr 11, 2020 at 12:30 AM Seth Arnold <1869792 at bugs.launchpad.net>
wrote:

> This is an awkward case, I'm not sure we've got a perfect plan here.
>
> u-boot has been in main for a while; a previous release did need to go
> through -security but it appears it wasn't for security reasons:
>
> https://launchpad.net/ubuntu/+source/u-boot/2016.01+dfsg1-2ubuntu3
>
> The rpi family does not have any secure boot mechanism. Most of these
> machines are hobbiest machines, quite often the storage is accessible
> without even undoing any screws, so it's easy to say the boot process is
> unlikely to be a security boundary.
>

Indeed - I'm operating on the assumption that we have no expectation of
security in the face of physical access to the device seeing as (as you've
noted) there's no secure boot, the storage is trivially removable, and
there's no encrypted file-system. The only issue I can envisage is whether
it opens the system to remote compromise (which *might* be feasible given
we do compile in the networking sub-system and TFTP / PXE-ish options,
though these are not (currently) used in our boot sequence).

So, with that in mind, I looked at only what's new, here:
>
> $ tar tf data.tar.xz
> ./
> ./usr/
> ./usr/lib/
> ./usr/lib/u-boot/
> ./usr/lib/u-boot/rpi_3/
> ./usr/lib/u-boot/rpi_3/u-boot.bin
> ./usr/lib/u-boot/rpi_3/uboot.elf
> ./usr/lib/u-boot/rpi_4/
> ./usr/lib/u-boot/rpi_4/u-boot.bin
> ./usr/lib/u-boot/rpi_4/uboot.elf
> ./usr/share/
> ./usr/share/doc/
> ./usr/share/doc/u-boot-rpi/
> ./usr/share/doc/u-boot-rpi/README.Debian
> ./usr/share/doc/u-boot-rpi/changelog.Debian.gz
> ./usr/share/doc/u-boot-rpi/configs/
> ./usr/share/doc/u-boot-rpi/configs/config.rpi_3.gz
> ./usr/share/doc/u-boot-rpi/configs/config.rpi_4.gz
> ./usr/share/doc/u-boot-rpi/copyright
> ./usr/share/lintian/
> ./usr/share/lintian/overrides/
> ./usr/share/lintian/overrides/u-boot-rpi
> ./usr/share/u-boot/
> ./usr/share/u-boot/rpi-config-migration
>
> $ tar tf control.tar.xz
> ./
> ./control
> ./md5sums
> ./postinst
>
> The .bin and .elf files are probably safe to treat as binary blobs from
> rpi and not worry about their maintenance.
>

Sorry - I may be a little unclear on your statement here? The .bin and .elf
files are from our build of u-boot - they're not provided by the rpi
foundation (the foundation don't use u-boot at all - only their own
bootloader firmware, which we also use, and which is a binary blob, but
that's in the linux-firmware-raspi2 package). In other words, we do have
the source for the u-boot.bin files (I'm not entirely clear why we include
the .elf files - they're not used for anything).


> The postinst and rpi-config-migration are a bit interesting. I don't
> understand why they are split apart. I'd feel better if the rpi-config-
> migration were run rather than sourced, just out of a sense of trying to
> reduce coupling between parts that are not obviously connected.
>

The split was made on the advice of the initial reviewer of those changes
in order to keep the postinst changes minimal (presumably so the top-level
logic made for a cleaner review). My hope is that, post-focal, the
rpi-config-migration stuff can be excised entirely (I only added it to move
upgraders from the single u-boot configuration used circa Bionic, to the
multi u-boot configuration we adopted in Eoan to support the Pi4).


> There's no shbang line for rpi-config-migration, no set -e directly in
> that file, and since it uses pipelines heavily, set -o pipefail would
> probably also be useful.
>

The lack of a shebang in rpi-config-migration was deliberate, as the intent
was that the file would only ever be sourced as a library of functions for
migration purposes. I was under the impression that was preferred for such
cases (e.g. /usr/share/flash-kernel/functions)? Likewise for the execution
options - but the pipefail point is a good one


> Security team ACK for promoting u-boot-rpi.
>
> If u-boot deserves a deeper look from the security team, we can arrange
> that. Giving it a deeper look before 20.04 release feels infeasible, and
> anyway this has been de-facto 'main' in all but process for a while
> anyway, right?
>

Inasmuch as it's been in the boot sequence of our all pi images since at
least Bionic (possibly Xenial?), yes - it's been de-facto "main" for years
:)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to u-boot in Ubuntu.
https://bugs.launchpad.net/bugs/1869792

Title:
  [MIR] u-boot-rpi

Status in u-boot package in Ubuntu:
  In Progress

Bug description:
  [Availability]
  The package is already in universe.

  
  [Rationale]
  The package is in use in the boot sequence on all supported Raspberry Pi images, both classic and core.

  
  [Security]
  While there are (recent) open CVEs against u-boot, none appear relevant to the RPi port specifically. Notably:

  * CVE-2020-8432 deals with a double-free in cmd/gpt.c; GPT_CMD is not
  enabled in our rpi related u-boot configuration (because the pi does
  not support GUID partition tables).

  * CVE-2020-10648 deals with bypassing verified boot restrictions on
  FIT images; we don't use FIT u-boot images on our pi builds.

  * CVE-2019-16258 deals with attackers gaining root access by
  manipulating the u-boot console via UART; there's no expectation of
  boot security against physical access to a pi so this is irrelevant.

  * CVE-2019-14192..14204 deal with stack-based overflows against NFS
  and RPC commands. While our u-boot-rpi build does include NFS
  commands, they are not used in our boot scripts.

  All further CVEs deal with versions prior to 2019.07 (the current
  version in focal). Although it is clear vulnerabilities are reported
  with some regularity against the package, it is also evident that
  upstream responds rapidly to such reports and that many don't apply to
  our usage of the package on the pi. Furthermore, the pi is a
  relatively "open" platform with little expectation of security against
  direct physical access (after all, the storage is removable and
  unencrypted) which negates several of the reported vulnerabilities.

  
  [Quality assurance]
  As mentioned above, the package is already in active use in the Pi boot sequence. There are no outstanding bugs which significantly affect the usability (i.e. our images boot successfully on all supported pi models) and no important bugs open.

  There is no meaningful test suite included in the package, but then
  for a bootloader dealing with a novel platform the ultimate test is
  "does it boot?", and each update of the package is extensively
  (manually) tested against the supported models.

  The current version of the package does build-depend against python2.
  This is an issue noted in an upstream report (Debian: #943273),
  corrected in the current version in sid
  (https://salsa.debian.org/debian/u-boot/-/commit/f8a0fc63adbe13e0a3365af9b03e8315f1328913),
  and hence will be corrected next time our package is synced with
  upstream.

  
  [UI standards]
  The sole interactive element is the u-boot console which is only expected to be used in the circumstance that the system is un-bootable. This is (hopefully!) a sufficiently rare circumstance that the lack of localization does not pose an issue (further, it's hard to see how a bootloader could be localized given it is running prior to the OS starting and thus without knowledge of user configuration).

  
  [Dependencies]
  The sole runtime dependency is "awk", the installation candidates for which (gawk or mawk) are already present in main.

  
  [Standards compliance]
  The package installs its binaries under /usr/lib which may seem odd for something essential to booting the system but this is merely a "storage location". These binaries are then copied (via postinst currently, hopefully in future via flash-kernel) to the more appropriate /boot hierarchy.

  
  [Maintenance]
  The package is maintained by the Ubuntu Foundations team.

  
  [Background information]
  As mentioned above the package is already in active use on all our Raspberry Pi images (both classic and core). It's only recently that it was brought to my attention that the package isn't in main already. The package is essential to both the classic and core boot experiences: in the classic case for providing unpacking duties for compressed kernels, and in the core case for handling A/B boot states (neither of these facilities is currently supported by the pi's own firmware bootloader).

  This package is currently pulled into the images via the "pi-gadget"
  (https://github.com/snapcore/pi-gadget) snap which forms the basis of
  both the classic and core pi images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1869792/+subscriptions