[MIR] linux-firmware-raspi2 to restricted

[Łukasz Zemczak]

1. Availability: The package is already available in multiverse and is already used on all of our Ubuntu Raspberry Pi images.

2. Rationale: As mentioned above, the package is already used on all of our Ubuntu Raspberry Pi preinstalled images (raspi) - and has been used there since the first raspi2 images have been supported. It is essentially a mistake that the package is still in multiverse, as we should not build images using packages outside of main and restricted.

3. Security: So far there has been no CVE or any security vulnerability reported for our package. Generally the package consists of binary blobs coming from the Raspberry Pi foundation.

4. Quality assurance: The package is easy to test and verify, as this is an essential package to the operation of Ubuntu on Raspberry Pi. It is maintained by Ubuntu Foundations, along with extensive QA on various Pi platforms.

5. Dependencies: The package has no dependencies (only shipping binary blobs).

6. Standards compliance: The licensing of the binaries is a bit ugly, but all the proprietary bits are well documented in debian/copyright.

7. Maintenance: The package is actively maintained by the Ubuntu Foundations team.

8. Background information:

As mentioned, this package is already used for all our images, so we are already treating it as a package from restricted per-se. So moving the package to restricted should only be a formality. All the hosted binary blobs are essential to our Ubuntu raspi experience, so we can't really do much without them.

Another important note: this package is not part of any seed right now, but instead pulled in via livecd-rootfs directly when building raspi images (we'll figure something better for the future).

[Christian Ehrhardt  (paelzer)]

In last weeks MIR meeting doko was assigned to review this (and discuss inside the team with sil2100 as needed).
I Updated the bug tasks to reflect that.

[Łukasz Zemczak (sil2100)]

Any progress on this? Do we have any guidelines/people that reviewed such binary-blob packages for multiverse before?

[Dimitri John Ledkov (xnox)]

These files come from RaspberryPi Foundation, who redistributed these firmware files without a restriction.

They support these blobs, and so do we, to ensure that hw is working correctly (i.e. bluetooth, wlan, etc).

If and when RaspberryPi releases updates to these blobs, Foundations team will be testing the update for regressions and updating these. Similarly whenever new Pi boards are released.

This is similar to linux-firmware package which has previously had a similar review to ensure that we can redistribute blobs for promotion from multiverse->restricted.

If any blobs shipped now, or in the future, loose ability to be redistributed we would then be forced to remove them. This is thus similar to intel-microcode/amd64-microcode packages too.

Please promote this package from multiverse to restricted.

[Christian Ehrhardt  (paelzer)]

Setting back to "new" so it shows up in our weekly (Tuesdays) MIR meeting lists.

@xnox - why have you unassigned doko, he was meant to do a MIR review as assigned in March.
I'd have supported pinging/asking him to do that, but unassigning - why that?

[Christian Ehrhardt  (paelzer)]

From a glimpse onto the package, I agree this is mostly like the cases of intel-microcode [1][2] and amd64-microcode [3] but will need a review still to be sure nothing awkward becomes supported.

@xnox - I'm curious; I'd still want to know if you had talked to doko before you unassigned him. What was going on (in background), ...?

[1]: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1388889
[2]: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1738272
[3]: https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1521174

[Christian Ehrhardt  (paelzer)]

copying the reasoning behind the unassign from IRC to the bug:
[16:32] <xnox> cpaelzer: i unassigned doko, because he has mentioned multiple times that he cannot review binary blobs. As there is no clear path on how to do RIR (restricted inclusion report)
[16:32] <xnox> cpaelzer: in practice some some of agreement between AA and MIR teams need to be made, to promote that one. The blobs are legit, and come from RPI foundation and we don't have restrictions on redistributing them.

Thanks for sharing!

Well nothing changed in regard to the next steps.
I already linked related bugs above and I'll do as much (a minor bit) of a review as possible applies and leave it to the AAs eventually who so far have done it.

P.S. and yes there should be a section added how this kind of cases shall be handled - but we don't need to block/gate on this case for that.

[Christian Ehrhardt  (paelzer)]

I gave this a review from the MIR POV under the constraint that this would likely be handled similar to the other firmware/microcode packages.

It is important to note that just looking at the source this would be a clear nack:
- precompiled kernel modules in ./modules
- precompiled shared objects in ./opt/vc
- many unsused source in ./hadfp/opt/
- GPU bins for 1001 drivers
...

This is Ubuntu only anyway and we use the code from https://github.com/raspberrypi/firmware/releases

If we could define a trivial but very effective source path filter and repackage this into a -dfsg like tarball with subtrees we don't need removed that would be awesoem.
After all MIR approvals are given on Source, and me (as well as likely the security Team later) probably would love to see a much much smaller source (since you only use so few of it).

It generally seems well maintained upstream and as a package. So yeah once this i trimmed down I'd give it a MIR ack and we can move it to the security-team.
If they ack as well then the Archive-Admins can make the final call of "yeah lets support it despite being blobs, like the other such cases".

For now re-assigning to Dave to come up with the reduced source (or to convince otherwise).

[Dimitri John Ledkov (xnox)]

@cpaelzer

https://launchpad.net/ubuntu/groovy/+queue?queue_state=1&queue_text=linux-firmware-raspi2

Now has a much better source package. I switched it to native, and it only contains the blobs that are shipped.

Hopefully it's much easier to review now. But also update.

The resultant .deb from this package is identical to the previous .deb. As that was the only bits we shipped from that monster.

[Christian Ehrhardt  (paelzer)]

I have checked the dsc+tarball from the queue.
Thank you a lot that looks much better now has my MIR +1 and can go to the security Teams review now.

[Dimitri John Ledkov (xnox)]

Horay. and it's now in the release pocket https://launchpad.net/ubuntu/+source/linux-firmware-raspi2/2-0ubuntu1

should be easy to review now, as it is squueky clean

[Dimitri John Ledkov (xnox)]

@paelzer

Why is security review needed? These are static closed source fw data-files.

[Christian Ehrhardt  (paelzer)]

Exactly @xnox - "These are static closed source fw data-files"

Which implies we should all want a ack here on the bug (for an audit trail) by Security that they are ok to ship it that way.

Yes we have other packages that do that, but maybe there are special precautions or deals made with their blob provider - I want to see such an ack to be sure we are not bypassing something by accident.

The only thing here, we want a "review of the case" not "a review of the code"

[Dave Jones (waveform)]

Pre-emptively, I'll leave the following here as it came up on the rpi-eeprom MIR:

Foundations team will handle regular importing of updated versions, and SRUing to all supported releases. Devices certification team will handle provision of testing resources and periodic testing of all supported releases.

[Seth Arnold (seth-arnold)]

I reviewed linux-firmware-raspi2 version 2-0ubuntu1 as checked into
groovy. This is very quick pass over the package.

My concerns for this package are nearly identical to my concerns given in
https://bugs.launchpad.net/ubuntu/+source/rpi-eeprom/+bug/1895137/comments/11
Thanks Dave for anticipating similar expectations for this package:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1867813/comments/13

One concern I have with this package is the get-orig-source target
downloads files without strong verification of file contents, it is
trusting the github infrastructure and x.509 ecosystem to make sure
incorrect files aren't downloaded by accident.

This isn't ideal but also isn't restricted to this one package.

Security team ACK for promoting linux-firmware-raspi2 to restricted.

Thanks

[Christian Ehrhardt  (paelzer)]

Ok, while being somewhat of a special case the bit that we can check from a MIR and security POV have been done.
It is now up to the archive admins to consider moving this as the other firmware packages - marking as fix-committed.

[Iain Lane (laney)]

laney@dev> ./change-override --suite groovy --component restricted linux-firmware-raspi2 ~/dev/canonical/release/ubuntu-archive-tools
Override component to restricted
linux-firmware-raspi2 2-0ubuntu2 in groovy arm64: multiverse/misc/optional/100% -> restricted
linux-firmware-raspi2 2-0ubuntu2 in groovy armhf: multiverse/misc/optional/100% -> restricted
Override [y|N]? y
2 publications overridden.