Thanks for the quick response, Seth! On Sat, Apr 11, 2020 at 12:30 AM Seth Arnold <[email protected]> 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869792 Title: [MIR] u-boot-rpi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1869792/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
