remove unfree HDCP blob from arm-trusted-firmware, closes #148890

[ghost]

Please see #148890 for an explanation of the problem.

I am submitting TWO PRs to close this issue; you may merge either one of them (it is not necessary to merge both)

This patch comes from https://gitlab.com/vicencb/kevinboot/-/blob/master/atf.patch

I have been running firmware with this patch on my daily driver rk3399
laptop for the past four months.

Motivation for this change

Please see #148890 for an explanation of the problem.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[lukegb]

For the record, the counterpart PR is #158309. Going to add to the discussion under #148890 rather than here, though, since it's more general about the philosophical change here.

[ghost]

the philosophical change here

It isn't a philosophical change; it corrects an oversight to bring licensing in line with longstanding policy.

I was very surprised to find CPU binaries without source code in a nixpkgs package whose license claimed unfree=false. I think most people would be. Otherwise what's the point? The current licensing for this package is inconsistent with pkgs/os-specific/linux/nvidia-x11/default.nix.

[ghost]

Note: I included the patch in the commit, rather than hash-referencing https://gitlab.com/vicencb/kevinboot/-/blob/master/atf.patch because minor changes to the ATF Makefile result in the original patch not applying correctly.

If you prefer I could find a way to minimize the committed patch so it only affects the Makfiles, and hash-reference vinceb's gitlab repo for the .c file changes. But I figured if we have to have a patch in nixpkgs anyways we might as well put all the changes in one place.

The RK3399 firmware is extremely stable; Rockchip is focused on their newer chips at this point. Any future merge conflicts should involve only the Makefiles (which ARM does seem to fiddle with now and then), and should be very straightforward to resolve.

[ghost]

I will be updating this patch to take the approach recommended by @lukegb here later tonight.

[ghost]

On an amd64 host with:

nix-build pkgsCross.aarch64-multiplatform.armTrustedFirmwareRK3399

1. I have verified that nixpkgs will refuse to continue with NIXPKGS_ALLOW_UNFREE!=1

2. I am currently verifying a with unfreeIncludeHDCPBlob=false. It is a large rebuild (I don't usually work off of master) which is why I am doing a crossbuild -- my amd64 machine has 32 cores and 64GB of memory and none of my arm64 machines are anywhere close to that. It should be done by morning.

[ghost]

Style feedback (even nitpicks) is welcome -- I have quite a number of patches that I'll be submitting over the next few weeks.

I managed to get mips64el to bootstrap (all the way up to building nix out of nixpkgs) and have a bunch of other patches to make the systemd dependency of many packages optional on non-darwin kernels.

[ghost]

Also let me know if you would prefer that I squash all three commits into a single commit.

[ghost]

ping

[lukegb]

Sorry for the delay, was hoping the listed maintainer would hop in with a review.

[lopsided98]

Sorry, I forgot about this PR. I wasn't aware of this blob and I think this is a good solution. cc @samueldr in case you're interested in this.

[samueldr]

Shouldn't this affect only RK3399 builds? Currently this affects all arm-trusted-firmware flavours, even if the blob is not in use.

Furthermore, I don't know if it really makes it unfree, given the binary is in the repository and assumedly must be released on the same terms as the project is. Though IANAL, so I do not know if there's some magic property of this particular license that means it can't apply to binaries.

[ghost]

I do not know if there's some magic property of this particular license that means it can't apply to binaries.

This was discussed already.

For software, the license field describes the license for the software's source code. Otherwise the licenses' unfree field would be meaningless, and the unfreeRedistributable pseudo-license would be equivalent to bsd and therefore unnecessary. This is not a feature of the particular license of this package, it is true uniformly across all licenses in licenses.nix (except the pseudo-licenses, which exist to indicate that the source code is unavailable).

Note that this is independent of, and orthogonal to, the question of whether or not the nixpkgs expression actually uses said source code to produce its outputs. That question is resolved by RFC 089.

Shouldn't this affect only RK3399 builds?

It only affects RK3399 builds. No other platform uses that file.

Perhaps you were asking if the patch should be applied only when building for rk3399? My understanding is that, in general, nixpkgs prefers that if a patch is to be applied and can be applied to all builds then it should be applied to all builds, so everything is building from the same source.

It is also very possible that Rockchip will release some future chip that has the same HDCP 2.0 decoder core, and some future release of arm-trusted-firmware will therefore need the patch for "RK9999 builds". This way we won't get surprised if that happens. They just released some "smart car AI" chip a year ago.

One possibility would be to set the default value of unfreeIncludeHDCPBlob to false on all platforms except rk3399, since doing so on those platforms would not produce any change in the resulting output.

Another possibility would be for unfreeIncludeHDCPBlob to default to false everywhere. Unfortunately this would be a silent breaking change for any preexisting rk3399 users.

[samueldr]

It only affects RK3399 builds. No other platform uses that file.

No other platforms use that files, but the license change affect other platforms.

Currently this means that any non-RK3399 arm-trusted-firmware build is being marked as unfree by this change.

[ghost]

No other platforms use that files, but the license change affect other platforms.

That is why I wrote:

One possibility would be to set the default value of unfreeIncludeHDCPBlob to false on all platforms except rk3399, since doing so on those platforms would not produce any change in the resulting output.

The current unfreeIncludeHDCPBlob approach wasn't my idea; it was requested here. This was my first PR submitted to nixpkgs so I went along with what the reviewer asked me to do.

[ghost]

#174691 (master) and #174690 (22.05 backport)