zfs: offer Linux kernel DRM circumvention option to enable ZFS on 6.2+

[RaitoBezarius]

Description of changes

Introduced in torvalds/linux@aaeca98 with the usual disdain for ZFS.

We have been there in the past with
https://www.phoronix.com/news/NixOS-Linux-5.0-ZFS-FPU-Drop / #61076.

This fixes ZFS on aarch64 until the next breakage.

See openzfs/zfs#14555 for original upstream issue.

I know this can have legal consequences for NixOS, I will submit myself to all scrutiny and bikeshedding :).

Things done

Tested through pkgsCross.aarch64-multiplatform.linuxPackages_6_2.zfs.

• 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/)
• 23.05 Release Notes (or backporting 22.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
• Fits CONTRIBUTING.md.

[dylanmtaylor]

I feel like a better approach is to hold off on shipping these packages for aarch64 until this is fixed upstream rather than effectively re-licensing code under the GPL without permission. This isn't as bad as patching ZFS to report that it is GPL, as suggested at openzfs/zfs#11357 (comment) but it's definitely not a great idea, IMO.

[RaitoBezarius]

I feel like a better approach is to hold off on shipping these packages for aarch64 until this is fixed upstream rather than effectively re-licensing code under the GPL without permission. This isn't as bad as patching ZFS to report that it is GPL, as suggested at openzfs/zfs#11357 (comment) but it's definitely not a great idea, IMO.

Well, the code was there at some point. This is not going to be fixed by the kernel upstream in any way atm. (I contacted kernel upstream with no avail).

OpenZFS upstream can reintroduce their own version of the trivial helper, but if, for some reason, there's a treewide change of the semantics of start/end, OpenZFS has to track them.

From a distribution point of view, this change minimize the breakage and the risks for the users.

[Mic92]

but it's definitely not a great idea, IMO.

There is zero impact on other users. This has nothing to do with re-licensing. The whole of the linux kernel is under the GPL before and after applying this patch. We don't need any permission to apply patches to Linux kernel. The license allows us to change code as long as we publish the changes, which is done by publishing the patch. If we would introduce a new kernel symbol that would expose the old function under a different name this would be also perfectly compliant with the GPL.

[Luflosi]

Suggested change

	{ lib, buildPackages, fetchurl, perl, buildLinux, nixosTests, fetchpatch, ... } @ args:
	{ lib, buildPackages, fetchurl, perl, buildLinux, nixosTests, ... } @ args:

This isn't needed, right?

[RaitoBezarius]

Correct

[Luflosi]

Is there an easy way to also patch the Raspberry Pi kernels once they are updated?
Nevermind, I see they can be patched in the same way.

[Ma27]

A while ago I stumbled upon this: https://lwn.net/Articles/154602/
There's some back and forth in the comments, but I'd like to highlight one thing: intent seems to matter when doing that and right now we're patching the kernel to get it to work with a kernel module that has a license being incompatible to GPL.

Of course, I'm not a lawyer and my interpretation may be wrong, however I'm pretty sure that if we're doing something we're not legally not allowed to, things can become nasty pretty quickly. Hence I'd advice to seek legal advice first.

If @armijnhemel has some time right now, they could help out for instance.

[Mic92]

A while ago I stumbled upon this: https://lwn.net/Articles/154602/ There's some back and forth in the comments, but I'd like to highlight one thing: intent seems to matter when doing that and right now we're patching the kernel to get it to work with a kernel module that has a license being incompatible to GPL.

Of course, I'm not a lawyer and my interpretation may be wrong, however I'm pretty sure that if we're doing something we're not legally not allowed to, things can become nasty pretty quickly. Hence I'd advice to seek legal advice first.

If @armijnhemel has some time right now, they could help out for instance.

This a review by an actual lawyer and not Linus Torvald itself: https://www.ifross.org/?q=en/artikel/ongoing-dispute-over-value-exportsymbolgpl-function

Nvidia’s recent proposal to remove the GPL label from the EXPORT_SYMBOL_GPL() directive covering the DMA buffer sharing mechanism (dma-buf) interface has once again raised the debate and caused a couple of interesting comments, including the suggestion that all copyright holders for the DMA sharing mechanism would have to approve the change. Consent of all copyright holders would indeed be advisable, if not required, but only if the EXPORT_SYMBOL_GPL() were considered to be a license restriction itself. Only if the GPL label can be seen to be part of the license, removing it would mean to change the license and in turn require approval by all copyright holders. However, interpreting the EXPORT_SYMBOL_GPL() as a license restriction raises a number of concerns. Firstly, it may impose a conflict with the wording of the GPL, which bans any further restrictions, and secondly, not all copyright holders have approved the GPL label in the first place, which – altogether - will make it quite difficult to consider the GPL label as a legally binding provision. Consequently, it seems more appropriate to argue that the GPL marker does not provide a license restriction itself, but qualifies as a technical access control mechanism, which can be better described as a digital rights management system (DRM). Whether the removal of such a DRM can have legal consequences under the respective copyright depends on different regulations in various jurisdictions and shall be subject of a separate analysis. But the general approach of reading the EXPORT_SYMBOL_GPL() as a technical rather than a legal mechanism still leads to another delicate question: If modifications in the code are legally permissible according to the underlying license (GPL v2 or compatible) would such modifications qualify as a derivative work according to the license and therefore be subject of the copyleft provision of sec. 2b) GPL?

In short this is DRM and does not change the license of the GPL itself.

[RaitoBezarius]

Here's a new approach which is more honest about what we are offering. :)
NixOS won't distribute ZFS kernels for 6.2+ this way, so I don't think there's any risk for the project anymore.

Anyone who wants to cache it and circumvent Linux access control/DRM protection for putting a CPU in the right mode for doing SIMD can now enjoy doing it in one flag.

[SuperSandro2000]

Suggested change

	Linux 6.2 dropped some kernel symbols required on aarch64 required by zfs.
	Linux 6.2 dropped some kernel symbols required on aarch64 by zfs.

[RaitoBezarius]

Closed in favor of #237873.