[MIR] u-boot-rpi
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| u-boot (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
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-
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:/
[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:/
| Changed in u-boot (Ubuntu): | |
| assignee: | nobody → Christian Ehrhardt (paelzer) |
| Christian Ehrhardt (paelzer) wrote | #1 |
| Changed in u-boot (Ubuntu): | |
| status: | New → Incomplete |
| Dave Jones (waveform) wrote Re: [Bug 1869792] Re: [MIR] u-boot-rpi | #2 |
| Christian Ehrhardt (paelzer) wrote | #3 |
| Changed in u-boot (Ubuntu): | |
| assignee: | Christian Ehrhardt (paelzer) → Ubuntu Security Team (ubuntu-security) |
| status: | Incomplete → New |
| Seth Arnold (seth-arnold) wrote | #4 |
| Changed in u-boot (Ubuntu): | |
| status: | New → In Progress |
| assignee: | Ubuntu Security Team (ubuntu-security) → nobody |
| Dave Jones (waveform) wrote | #5 |
| Christian Ehrhardt (paelzer) wrote | #6 |
| tags: | added: id-5e8ddba5c9cc7f7376c539d2 |
| Changed in u-boot (Ubuntu): | |
| status: | In Progress → Fix Committed |
| Changed in u-boot (Ubuntu): | |
| status: | Fix Committed → Fix Released |
Usually we are not doing per-arch decisions, MIR reviews are based on a source package.
But there were excuses in the past - and in this case it is not that much "per arch" even though u-boot-rpi sounds that way.
u-boot-rpi is one of multiple binary packages produced by src:u-boot.
Also these are only built on arm*
u-boot | 2019.07+
u-boot | 2019.07+
u-boot-rpi | 2019.07+
And in fact src:u-boot already has an approved MIR at https:/
So we are essentially re-reviewing just the sub-portion of u-boot that is responsible for u-boot-rpi.
Also foundations is already subscribed and maintains this (the changelog history is frequent)
$ ./get-packages-
u-boot
So it is actually already as close to main as it can be in terms of:
- maintenance
- src:pkg in main
- usage in RPI boot path
I agree that we should promote the package as well.
d/rules isn't the cleanest I've ever seen, but I'm still waiting to see the rom/bootloader that would be that way.
It has build-time tests and while autopkgtests are hard it is essentially used all over the place on any RPi testing.
The build log looks
None of the typical other checks (python, go, linking, ... apply to this package)
So the addition of u-boot-rpi looks mostly good from a MIR POV.
@David:
- the package appears to get regular updates/fixes by the foundations team
- upstream releases ~quarterly
- it might be too late for the brand new 2020.04~rc4, but what is the reason to not update to 19.10 or 20.01?
- Debian has 20.01 in testing and 20.04 in testing, so their speed is fast
- Is there an active maintenance and update policy in place or is it randomly updated as needed?
- sometimes packages tend to be outdated by accruing to much delta that is hard to rebase&maintain; It seems the packaging was split mid last year on 2019.04+
To be clear I don't request to do these updates for Focal (it is too late), but I'd want to see some reassurance that this is under control and e.g. will get a rebase soon once 20.10 opens.
Marking incomplete until this is clarified.
Note:
If the above is ok (I assume it will be) we can hand over to security since the old bug had no explicit security check as far as I can see and as you outlined other binary packages of the same source have known CVEs I'd want security to:
a) review for u-boot-rpi
b) state that it is ok to add this to main with known CVEs in other binaries of the package (not that this might e.g. break their CVE tracking)