Making life (even) harder for proprietary modules
Back in 2006, there was a brief effort to ban the loading of proprietary kernel modules altogether. That attempt was shut down by Linus Torvalds for a number of reasons, starting with the fact that simply loading a proprietary module into the Linux kernel is, on its own, not a copyright violation; it is something that any Linux user is allowed to do. Trying to ban such modules, Torvalds said, would be an indication that the development community is more interested in arguing about licenses than in improving the technology.
Distributing a proprietary module might be a copyright violation, though, if the module itself is a derived work of the kernel code. But "derived work" is a fuzzy concept, and the kernel itself cannot really make that judgment. There is a longstanding mechanism in the kernel designed to keep infringing modules out, though: GPL-only exports. A kernel module cannot do anything useful without accessing symbols (functions and data structures) exported to it by the kernel. Many of those symbols are restricted to modules that have declared a GPL-compatible license, thus fencing proprietary modules away from a lot of kernel functionality.
In theory, the GPL-only marking indicates that a symbol is so deeply tied into the kernel that any code making use of it must necessarily be a derived work of the kernel. In practice, the developers making those decisions do not carry out an analysis to determine whether that is the case — and they are not usually qualified to do such an analysis anyway. Instead, symbols are routinely marked GPL-only as a way of making life harder for proprietary modules in general.
To the surprise of, well, almost nobody, the creators of proprietary modules have long sought ways around the limitations imposed by GPL-only exports. This has included falsely declaring a GPL-compatible license, but doing so is such an overt admission of guilt that companies instinctively avoid it. Instead, they look for more subtle ways to get the access they need. One scheme was inadvertently revealed in 2020 as part of a larger patch set intended to make a form of peer-to-peer DMA work. If a module declares itself to have a GPL-compatible license, it will have full access to all of the symbols exported by the kernel. If that module then imports symbols from a proprietary module, it can serve as a go-between, making the full kernel available to the proprietary code. This is a variant of the often-used "GPL condom" approach.
At that time, Hellwig merged a patch intended to make that method more difficult. In current kernels, any module that uses symbols from a proprietary module is treated as being proprietary itself; it immediately loses its ability to access GPL-only symbols. If the module has already gained access to any GPL-only symbols, any attempt it makes to import symbols from a proprietary module will fail. This check breaks the ability of a module to serve as a go-between, sending proprietary-module vendors scurrying back to their lairs complaining about how they have been foiled again.
There is always another way, though, it seems. The kernel provides a macro called symbol_get(), which turns around and calls __symbol_get() to do the real work, which happens to be looking up the address associated with a kernel symbol. This function, which has been in the kernel since the 2.5.48 release in 2002 (where it was added as a part of the wholesale replacement of the module loader), has a specific limitation, though: it only looks up symbols provided by loadable modules. It is intended for use with tightly linked modules that need to reference each other in situations where one of the modules may not be loaded, and without creating reference loops. By appearances, it cannot be used to find the location of GPL-only kernel symbols, and would seem to be of little use for proprietary-module vendors trying to bend the rules.
What symbol_get() can be used for, though, is obtaining addresses from a proprietary module without going through the normal import mechanism (and its restrictions). It can, in other words, be used to circumvent the 2020 fix, making it once again possible for a nominally GPL-licensed module to call into a proprietary module and give that module access to the kernel functionality it needs. Hellwig has asserted that NVIDIA, a company long known for its proprietary kernel modules, has duly modified its code to make use of this workaround.
In response, he posted this patch set (since revised) to close the hole once again. It changes the behavior of symbol_get(), causing it to fail when asked to look up a symbol that is not marked GPL-only. This is an inversion of the usual test, which denies access to symbols that are marked GPL-only. The reasoning is that symbol_get() has always been intended for low-level cooperation deep within the kernel, where everything is expected to be GPL-only anyway. As it happens, a handful of the uses in the kernel were for symbols that were not so marked, so the patch set includes changes to make the symbols referenced in those cases GPL-only.
The symbol_get() change also, coincidentally, makes it impossible for a GPL-licensed kernel module to resolve symbols defined inside a proprietary module using symbol_get(). Once this change finds its way into a mainline release and, from there, into distributions, the developers of proprietary modules will have to find another way to gain access to the kernel internals they need. The change has been applied by module maintainer Luis Chamberlain, so the chances of it going into the mainline eventually seem fairly good.
Given how long this conflict has been simmering, there is little doubt that
authors of proprietary modules will find another way to bypass the intent
of the kernel community. Proprietary or not, modules are running within
the kernel's address space, so the attack surface available to any module
attempting to circumvent the kernel's symbol-access policies is large and
can probably never be properly secured. The best that can be done is to
continue to make life uncomfortable for those who would ship binary-only
kernel modules in the hope that they eventually take the hint and create a
freely licensed solution. It is not a perfect technique, but it has often
worked over the years.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | Modules/Exported symbols |
| Kernel | Releases/6.6 |
Posted Aug 3, 2023 17:59 UTC (Thu)
by hailfinger (subscriber, #76962)
[Link] (2 responses)
Back then, the complaint was that MODULE_LICENSE checks were circumvented by inserting a "\0" into the license declaration:
String comparisons stop at the first "\0", so the module loader didn't complain.
Posted Aug 3, 2023 20:41 UTC (Thu)
by NUXI (subscriber, #70138)
[Link] (1 responses)
I'm the Jon from that email thread. Can't believe that was 19 years ago now.
Posted Aug 4, 2023 5:34 UTC (Fri)
by saladin (subscriber, #161355)
[Link]
How's that for a throwback?
Posted Aug 3, 2023 20:24 UTC (Thu)
by flussence (guest, #85566)
[Link] (24 responses)
Posted Aug 3, 2023 20:32 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
That's where they're headed, but they're not yet there - most installs of the NVIDIA driver will use the traditional proprietary module, not the GPL one.
It looks like the GPL driver relies on there being a microprocessor on the GPU that can run most of the "old" proprietary driver code, reducing the kernel driver to interfacing userspace to that microprocessor. This has advantages for nouveau replacements, in that you can reuse the NVIDIA firmware blob with Free userspace code, but is basically about moving the proprietary code off the CPU into a processor inside the GPU.
Posted Aug 11, 2023 8:18 UTC (Fri)
by jengelh (guest, #33263)
[Link] (1 responses)
Ironic to see how we're going back to how things were done ~30 years ago, when functionality was in fact on the daughterboard and didn't take up so much resources of the main system (particularly CPU cycles?).
Posted Aug 11, 2023 10:27 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Somewhere I remember it being discussed, and how it's all just a trade-off. Back in the days of winmodems and winprinters, the cpu was cheaper than dedicated power on the network card / in the printer, so cost conscious manufacturers moved all the compute into the cpu. Before that, the cpu was too slow and dedicated silicon was a better choice. Now with powerful GPUs it's swinging the other way - separate GPUs are both cheaper and faster.
And even with things like AMD's APUs, I get the impression they are actually a CPU and a GPU sharing the same chip, so they are actually separate silicon, just right next to each other to make things run faster with shared cache and physical proximity.
Cheers,
Posted Aug 4, 2023 2:51 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
Posted Aug 4, 2023 13:20 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (19 responses)
My understanding is that Nvidia didn't truly open their driver but instead move a lot of functionality over to proprietary firmware. Is that not the case?
Posted Aug 4, 2023 14:46 UTC (Fri)
by jgg (subscriber, #55211)
[Link] (12 responses)
Most of the server HW these days is some open driver that talks to some FW thing. Linux on servers pretty much runs inside a cacoon of propritary FW/SW layers.
An open driver that can drive a FW interface is still an open driver, at least as far as Linux is concerned.
Open HW and Open FW is an interesting philisophical position, there are definately groups pushing that way, but Linux kernel is not.
Posted Aug 4, 2023 14:55 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (11 responses)
Sure but my question was more specific than that. Did Nvidia open up their driver as it is or did they open it up after moving critical functionality to a proprietary firmware.
Posted Aug 4, 2023 15:18 UTC (Fri)
by pizza (subscriber, #46)
[Link] (5 responses)
Please don't tell me you agree with the FSF that proprietary firmware is okay as long as it's not upgradable/replaceable by the user.
Every piece of hardware in [1] or connected to [2] the system I'm typing this on is running proprietary firmware. Some of it is loaded at runtime [3], but most of it is not. All of them have "Critical functionality" [4] implemented in proprietary firmware yet have fully Free Software drivers that are part of the mainline Linux kernel.
nVidia moving to this approach (for the hardware that is capable of operating like this) represents a massive improvement over the old status quo and should be applauded, yet instead we're giving them grief for not going above and beyond what the "good guys" [5] are doing.
[1] CPU, BIOS/embedded controller, ethernet controller, wifi controller, display controller, both SSDs, DVD drive, and so on.
Posted Aug 4, 2023 19:35 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (4 responses)
Why? I see a minor reliability improvement by separating the Linux kernel code to be handled as a complete software package under the control of the Linux kernel community, and nVidia doing everything under the control of its subcomputer. But it does little or nothing to make the computer code more available to be examined or fixed, more open.
Posted Aug 4, 2023 20:44 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Going forward both nVidia's proprietary and F/OSS userspace build on top of the same kernel driver and device firmware. That driver can be mainlined and kept up to date with ongoing kernel developments. The amount of necessary proprietary code has shrunk significantly, and in the longer run, only the device firmware will remain proprietary. This is effectively identical to what AMD has been doing for many years now, and what pretty much every other modern hardware vendor also does.
Would it be nice if nVidia would open up their hardware entirely? Of course! But the overwhelming majority of the hardware the Linux supports has _always_ been proprietary, including all of what nVidia's competition produces.
Posted Sep 20, 2023 7:53 UTC (Wed)
by daenzer (subscriber, #7050)
[Link]
While the open source nvidia driver might be mainlineable in principle, Nvidia have not committed to doing so. So I wouldn't hold my breath.
(I don't know if they have committed to phasing out the proprietary driver in favour of the open source one)
> This is effectively identical to what AMD has been doing for many years now, [...]
Still quite a long way off, really. The amdgpu driver has been upstream for almost a decade (after years of preparation), and it contains pretty extensive documentation of how the hardware works.
Being an upstream driver, amdgpu has to maintain backwards compatibility with older firmware versions. I don't know if Nvidia have committed to doing the same for their open source driver.
Posted Aug 4, 2023 21:02 UTC (Fri)
by mfuzzey (subscriber, #57966)
[Link]
Firstly it's better from a security / auditability point of view. Of course the closed firmware could still do nasty stuff but code running on an external device is significantly more limited in things it can touch than kernel code, especially if there is an IIOMMU as is usually the case these days.
Secondly closed firmware does not constrain the whole system the way closed software does. By definition firmware only has to run on the hardware (external chip) it is intended to support. For example if you want to use a closed source kernel driver on an architecture it wasn't built for (Risc V for example), you're out of luck, you can't recompile it. But if you have an open source kernel driver you can recompile it to support any CPU that Linux runs on with the firmware blob only needing to run on the external hardware so not caring about the CPU architecture.
Of course, it would be even better to have open source firmware too but open kernel drivers are still a step in the right direction.
Posted Aug 30, 2023 17:50 UTC (Wed)
by cstrahan (guest, #104863)
[Link]
Sure. But it does make things better in a couple important ways: If NVIDIA wants to shove critical functionality into firmware blobs, at least the experience of using NVIDIA GPUs will suck equally everywhere. In practice, that means that they'll either work harder (than they would writing Linux kernel module code) to get things right, or if they can't, then they can be punished in the market, and we can all opt to acquire competing cards.
And while you and I would prefer to have access to all of the code, this move is still better than before for another reason: while the GPU may be stuck with buggy firmware blobs, at least that's not running in kernel space, with the power to crash your system.
Maybe an analogy would help: If I order food delivered, the delivery driver may take a crazy, convoluted route through town, and he may curb his vehicle, or get in a wreck, etc, and I don't have any control over that. But do you know what the delivery driver *isn't* going to do? Any of the above to *my* vehicle. If I *could* control the delivery driver's actions, I would have them safely and optimally delivery my food, but because I can't, at least I'll be happier knowing that they can only total their own car, while my car is sitting safely in my garage.
Having the proprietary NVIDIA kernel module loaded is like handing your keys over to a delivery driver you have never met and trusting they won't financially ruin you.
Posted Aug 4, 2023 15:42 UTC (Fri)
by jgg (subscriber, #55211)
[Link]
NVIDIA provided an open GPL-compatible licensed driver and a closed FW. Just like the majority of server HW out there these days. This new FW is NVIDIA's primary FW for all new HW. It is is not some special crippled open source release.
If you are familiar with the NVIDIA ecosystem you can see that the new FW and open source driver support the entire propritary userspace NVIDIA software stack. Today. This means everything you can do with CUDA/etc can be done through this FW.
So was "critical functionality" blocked off somehow? I guess not.
I think the more productive way to look at the situation is to ask what can be done on the open source side with this FW interface.
DRM maintainers have long held that an open userspace and open compiler are essential parts they need to consider something open.
It appears this FW is good enough that nouveau can make an open vulkan graphics stack, running at full performance, using the open userspace compiler that already exists. This is a big improvement.
If this FW release made nouveau, and its fully open stack, dramatically better - is it more or less open source friendly?
Posted Aug 4, 2023 16:47 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
NV moved all of the "proprietary" information to a microprocessor inside the GPU, which runs a large firmware blob. This blob does much of what used to be done on the host CPU by the driver, but on-GPU instead of on-host.
The kernel-mode driver thus does much less work than it used to do, because instead of handling low-level details of the system, it uses higher-level communications with the firmware blob to do its work. Nouveau and similar can use this directly, since they're able to talk the same higher-level interface; in this regard, it's similar to a modern x86 CPU with all its embedded controllers doing power management and the like, just with the firmware for those ECs uploaded at runtime, not stored in ROM or the boot firmware Flash chip.
Posted Aug 4, 2023 17:10 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Thank you for actually answering the question. The other responses here were much more evasive on this. FWIW I do think it is an improvement over the prior status quo but the details here matter.
Posted Aug 4, 2023 17:59 UTC (Fri)
by jgg (subscriber, #55211)
[Link] (1 responses)
Nobody really knows what NVIDIA did because the open source community cannot see inside the old propritary driver. We can assume that everything in the FW used to be on the CPU, we have no idea what % that is, certainly we have no idea if it is "most". We don't know if it is "critical", or whatever. It is obviously all the "proprietary" information, but who knows what that actual functionally is. A huge amount of code was still released in the open driver.
There is lots of clues in the open driver and in nouveau's use of the FW that gives some light on what kind of stuff must be in there, but I've never seen anyone publish some robust assesment.
Posted Aug 4, 2023 20:00 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
I found answering questions with other questions evasive. In any case, I don't see any disagreement that some functionality has moved over into the proprietary firmware, so I have the answer I was looking for. Let's move on.
Posted Aug 5, 2023 5:24 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Some of "secret sauce" remains in the closed userspace part, just like with AMD. But I don't believe that they actually moved functionality that is important for the kernel driver into the firmware.
Posted Aug 9, 2023 21:02 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (4 responses)
I don't believe that's true. The new open-source driver only works with the GSP-enabled generations, starting with Turing.
> Some of "secret sauce" remains in the closed userspace part, just like with AMD. But I don't believe that they actually moved functionality that is important for the kernel driver into the firmware.
Let's discuss an example.
For instance, one of the long-standing issues with NVIDIA's GPUs was power management, specifically reclocking. On those generations where reclocking was successfully reverse-engineered and implemented in nouveau, the driver was able to change the clocks at will (and overclocking was likely possible).
Now, I did not look at the "new" open-source kernel driver code, but I bet that the reclocking decisions are made entirely by the "new" proprietary firmware, while the kernel driver merely indicates the desired power state (or maybe even less than that, maybe it's only possible to indicate the upper limit). I also bet that there is zero support for overclocking, such that it remains a Windows-exclusive feature.
Does this "new" open-source code make it possible for nouveau to implement "some" support for reclocking? Yes. Will it be even remotely as useful as the hypothetical (reverse-)engineered interface to the low-level firmware? Not at all.
Posted Aug 9, 2023 21:35 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
I mean that the OpenSource driver doesn't need a special firmware for it.
> For instance, one of the long-standing issues with NVIDIA's GPUs was power management, specifically reclocking. On those generations where reclocking was successfully reverse-engineered and implemented in nouveau, the driver was able to change the clocks at will (and overclocking was likely possible).
Noveau still used firmware for reclocking, even on older devices. See: https://www.phoronix.com/forums/forum/linux-graphics-x-or...
Posted Aug 10, 2023 2:11 UTC (Thu)
by intelfx (subscriber, #130118)
[Link]
Then this does not address GP's concerns at all.
> Noveau still used firmware for reclocking, even on older devices
Nope, they wrote their own PMU firmware for supported devices.
Posted Aug 9, 2023 21:39 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
This "new" codebase is infinitely more useful than the current status quo, which prevents _any_ reclocking because nVidia locked things down cryptographically. Furthermore, attempting to tinker with those cryptographic locks exposes oneself to massive civil (and possibly criminal) liabilities in most jurisdictions.
nVidia has gone from actively impeding development of functionally useful F/OSS GPU drivers for their hardware to actively helping. This represents a massive improvement; why do you feel the need to dump on it for not being perfect?
Posted Aug 9, 2023 21:59 UTC (Wed)
by intelfx (subscriber, #130118)
[Link]
Could you please point out how exactly "attempting to tinker with cryptographic locks" on the hardware I legally own exposes me to liabilities "in most jurisdictions"? I fear I might need to turn myself in and report most of my friends and relatives :-)
If this is about DMCA, then, thankfully, USA != most jurisdictions. And even then, jailbreaking is exempt.
Posted Aug 3, 2023 21:02 UTC (Thu)
by geofft (subscriber, #59789)
[Link] (5 responses)
> One scheme was inadvertently revealed in 2020 as part of a larger patch set intended to make a form of peer-to-peer DMA work.
I don't really understand what happened here (https://lwn.net/Articles/827596/, https://lwn.net/ml/netdev/20200728163100.GD4181352@kroah....) - the patch was posted by Facebook, not NVIDIA, and Greg K-H insisted that it get approval from a corporate lawyer, presumably meaning Facebook.
Facebook doesn't (I assume) have any rights to sublicense NVIDIA's code, nor were they writing code that required such rights. The code they posted could have been written by anyone who received an ordinary proprietary license of the NVIDIA driver.
Furthermore, Facebook isn't redistributing any proprietary drivers. The patchset mentions mlx5, i.e., Mellanox - it's pretty clear that the use case here is server-class machines in Facebook data centers where they want to squeeze every bit of zero-copy performance out of multi-machine GPU workloads (either actual graphics processing or machine learning), not Oculus devices or anything.
By the same argument Linus made that loading a proprietary module into the kernel is not a copyright violation, patching your local kernel to better support proprietary modules (e.g., replace EXPORT_SYMBOL_GPL with EXPORT_SYMBOL or reverting this current tightenting of symbol_get), for internal use alone, is not a copyright violation either, right? I can certainly see the argument that this last patch isn't upstreamable (and the patchset said it was an RFC patchset, and made it relatively clear that this wasn't really going to be upstreamable), and I can maybe see the argument that it was rude to ask the kernel maintainers to code-review a use case that they don't support, even if such a use case is legal. But that's it, right? What would Facebook's corporate signoff have added?
Or in other words - this module wasn't a bypass of anything, right? It did something that is perfectly well permissible by the current rules (and doesn't involve any copyright violations, assuming you don't believe the NVIDIA driver itself is one) - it's GPL'd code (actually GPL'd, because it was published to LKML!), which is a derivative work of two things, the Linux kernel itself and the proprietary NVIDIA driver. It links, in normal ways, symbols exported from the core kernel as well as symbols exported from NVIDIA. It wasn't being done at NVIDIA's behest to increase the capabilities given to the driver - it was being done by an end user.
Maybe the idea is that things that are derivative works of both the kernel and a proprietary module should be disallowed? If so that actually seems relatively easy to enforce: don't let GPL'd modules depend on non-GPL'd modules. Would that break any extant use cases?
Posted Aug 3, 2023 22:06 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
There are some issues to consider with that:
1. If it is a derivative work of NVIDIA's code, then it infringes NVIDIA's copyright unless they have given permission to use it. See e.g. 17 USC 106(2) (and comparable laws in just about every jurisdiction in the world).
> If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.
In other words: If your purportedly GPL'd code violates someone else's copyright, then the GPL recognizes that fact and forbids you from distributing it in violation of that copyright. This is important, because otherwise, we would have a huge GPL loophole. You could have company X write some proprietary code, company Y release a derivative work of X's code under the GPL (without X's permission), and then company Z tries to use Y's purportedly GPL'd code in compliance with the GPL, only for X to sue Z and not Y (X is under no obligation to enforce their copyright uniformly against everyone - copyright is not trademark). The net result? GPL'd code that you can't safely use or build on. The FSF foresaw this problem and added a clause to the GPL explicitly forbidding it.
Or at least, that is the way it has been explained to me. It is also possible to read this passage as simply clarifying that the GPL is not subject to the impossibility or frustration of purpose doctrines (i.e. it prevents people from going into court and saying "your honor, complying with the GPL would violate this other contract..." and thus excusing themselves from GPL compliance), and not as imposing a substantive obligation on the licensee. I don't know if this has ever been litigated.
3. If NVIDIA *has* given permission to create this sort of thing (e.g. in their EULA), then the fact that it's being done by Facebook and not NVIDIA is immaterial. NVIDIA could just as easily do it themselves.
Posted Aug 3, 2023 22:20 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
It's not quite immaterial; if the resulting work is a copyright infringement of someone else's work (e.g. the Linux kernel), then the fact that it's done outside NVIDIA protects NVIDIA from being ordered to open up their proprietary driver as a remedy for infringement.
This is very much a corner case, since courts rarely order that sort of specific performance where monetary damages are possible, but it gives NVIDIA a reason to prefer to give permission and let someone else do it rather than do it themselves.
Posted Aug 3, 2023 22:13 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (2 responses)
Posted Aug 11, 2023 15:38 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (1 responses)
Posted Aug 11, 2023 15:56 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
The problem with that is the people who don't bother to check the facts (ie most of us, most of the time).
As I put it, "your reality is not my reality", or as Einstein would put it, "what you observe depends on where you are standing". There are too many people who cannot understand how anyone else could have a different point of view. (One only has to look at the recent "heated discussion" over Free Software and Open Source :-)
So let me rephrase your comment - Once someone's tinted glasses have given them reason to believe you have acted in bad faith ... it happens, and it probably happens far more often than it should ...
We've seen it happen here, where people just refuse to accept that somebody else (Red Hat, anyone) might have had good grounds for doing what they've done.
Cheers,
Posted Aug 3, 2023 22:25 UTC (Thu)
by jreiser (subscriber, #11027)
[Link] (3 responses)
Posted Aug 3, 2023 23:43 UTC (Thu)
by willy (subscriber, #9762)
[Link] (2 responses)
Posted Aug 4, 2023 10:30 UTC (Fri)
by dullfire (guest, #111432)
[Link]
Posted Aug 5, 2023 5:18 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Aug 4, 2023 14:14 UTC (Fri)
by spmfox (subscriber, #125241)
[Link] (28 responses)
Posted Aug 4, 2023 17:07 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (25 responses)
Posted Aug 4, 2023 17:31 UTC (Fri)
by spmfox (subscriber, #125241)
[Link]
So until that happens, yeah I'd like ZFS to keep working and not have the dev's work be harder to do.
Posted Aug 4, 2023 19:29 UTC (Fri)
by darmengod (subscriber, #130659)
[Link] (8 responses)
There really *is* no substitute, it's a fantastic filesystem (storage stack?) and nothing in the Linux ecosystem quite compares to it yet.
Posted Aug 4, 2023 23:44 UTC (Fri)
by shemminger (subscriber, #5739)
[Link] (7 responses)
Posted Aug 5, 2023 7:20 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
This is not an idle question. If it doesn't make them any money, then they will not do it. See discussion in https://youtu.be/-zRN7XLCRhc?t=2085 for more information.
Posted Aug 5, 2023 9:03 UTC (Sat)
by james (subscriber, #1325)
[Link] (5 responses)
Traditionally, ZFS was a reason to buy Solaris, but with that going end-of-life in 2034, very few enterprises are going to do fresh installs on Solaris. ZFS is no longer a killer feature for Solaris.
But if ZFS is a first-class filesystem on Oracle Linux, that might encourage clients to buy support from Oracle even if other distros have it. It would certainly help sell Oracle Linux instead of Windows.
Posted Aug 5, 2023 19:10 UTC (Sat)
by willy (subscriber, #9762)
[Link] (4 responses)
Posted Aug 7, 2023 12:47 UTC (Mon)
by james (subscriber, #1325)
[Link]
I'm saying that it would be worth Oracle's while to allow ZFS into the Linux kernel and support it on Oracle Linux: this wouldn't negatively affect commercial Solaris (since its days are numbered), but would benefit Linux in general and Oracle Linux in particular.
Posted Aug 8, 2023 16:42 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
This is also the answer to NYKevin's question: Oracle could make more money by relicensing ZFS to be GPL compatible as that would allow them to ship ZFS with Oracle Linux, and market it as "We invented it, so we can support it best!".
The slight problem there is that a lot of ZFS on Linux development has been done outside of Solaris, and most (all?) of the Sun ZFS developers have long left Sun/Oracle.
Posted Aug 11, 2023 16:34 UTC (Fri)
by BenHutchings (subscriber, #37955)
[Link] (1 responses)
Posted Aug 11, 2023 18:38 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 5, 2023 7:12 UTC (Sat)
by cyphar (subscriber, #110703)
[Link] (13 responses)
Critically, in contrast to the shenanigans of proprietary module developers -- ZFS is free software under a copyleft licence, and does not attempt to subvert Linux's module loading license rules. I'm sure the OpenZFS developers would love it for it to be accepted by Linux as a first-party filesystem. They are not the bad guys here.
The licensing issue is very unfortunate, I understand the trepidation. But let's not paint people who work on CDDL code with the same brush as out-of-tree developers who seem to enjoy making things worse for everyone.
Posted Aug 5, 2023 7:26 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (12 responses)
Posted Aug 5, 2023 7:42 UTC (Sat)
by cyphar (subscriber, #110703)
[Link] (11 responses)
As for the CDDL-1.1-only code, I don't know which developer you are referring to, but unless they've explicitly stated that they wouldn't want their code to be GPL-compatible, it's also possible they were worried that CDDL could be changed by Oracle to allow for proprietary forks (if they did, it would allow them to use OpenZFS in their proprietary ZFS fork). As usual in license discussions, the risks cut both ways.
Posted Aug 5, 2023 9:37 UTC (Sat)
by snajpa (subscriber, #73467)
[Link] (10 responses)
Posted Aug 5, 2023 12:58 UTC (Sat)
by pizza (subscriber, #46)
[Link] (9 responses)
Intents only matter when the text is ambiguous, which is not the case here.
The fundamental conflict between the CDDL and the GPL is that they both require derived works to be licensed solely under that license. While broadly similar, the licenses are not identical, and the differences (eg the CDDL has stricter patent language) become "additional restrictions" that are not allowable under the other. Therefore the licenses are incompatible.
Oh, it's a lot more than the linux kernel community saying this -- Sun folks are on the record saying the CDDL was intentionally drafted to be incompatible with the GPL, and pretty much every F/OSS lawyer (other than the ones on Canonical's payroll) also agrees on this front.
Sure, ultimately it's up to a court and a zealous deep-pocketed plantiff to test this, but while you can probably trust a typical Linux contributor to not stir the pot, OpenZFS's rights are still largely held by Oracle, whose lawyers have shown time and time again they will happily boil the oceans if they think they can get away with it.
Posted Aug 6, 2023 3:38 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
I'm not sure that's a fair characterization of the issue. The SFLC has a long and nuanced post on the issue (see [1]) which I would summarize as "it's complicated, but arguing over ZFS on the internet is not a productive use of anybody's time. The kernel developers should either send Canonical a C&D letter, or stop whining."
[1]: https://softwarefreedom.org/resources/2016/linux-kernel-c...
Posted Aug 6, 2023 12:46 UTC (Sun)
by pizza (subscriber, #46)
[Link] (7 responses)
As I said in the message you replied to; its not the kernel authors that Canonical (or the other kernel devs) should worry about; Instead it's Oracle's lawyers, who are well known for suing over software licensing minutae.
Posted Aug 6, 2023 17:06 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
Posted Aug 6, 2023 22:41 UTC (Sun)
by pizza (subscriber, #46)
[Link] (4 responses)
Perhaps Oracle doesn't think Canonical has deep enough pockets to be worth suing, and is biding their time unti a more lucrative target (if only Canonical in a few more years) presents itself?
As both the stewards of CDDL and copyright holder of most of the ZFS codebase, Oracle could make this problem go away completely if they wanted to. Yet they have not.
Posted Aug 8, 2023 5:39 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
They could still sue for ongoing infringement after that point, assuming Canonical continues to distribute ZFS, but common law jurisdictions may apply the doctrine of laches if the plaintiff was aware of the infringement and intentionally delayed enforcement to prejudice the defendant, regardless of whether the statute of limitations applies. See for example Danjaq LLC v. Sony Corp., 263 F.3d 942 (9th Cir. 2001).[2] The key quote (in my opinion):
> Next, we conclude that claims of infringement stemming from re-releases of Bond movies on DVD have been "delayed" for purposes of laches. On the one hand, we recognize the seemingly paradoxical nature of this conclusion. After all, how can it fairly be said that a lawsuit filed in 1998, relating to a DVD released in 1997 (to take the example of Dr. No) was "delayed"? The answer is simple: Where, as here, the allegedly infringing aspect of the DVD is identical to the alleged infringements contained in the underlying movie, then the two should be treated identically for purposes of laches. It would be incongruous indeed to hold the opposite — to say, that is, that McClory's claim for infringement on a re-release survives, despite the dismissal for laches of the same claim regarding the original work. This exception would effectively swallow the rule of laches, and render it a spineless defense. In analogous contexts, similar theories have been roundly rejected. See, e.g., Hot Wax, Inc. v. Turtle Wax, Inc., 191 F.3d 813, 821-22 (7th Cir. 1999) (trademark case; rejecting the argument that each new instance of infringement must start the clock anew on laches: "Without the availability of the application of laches to a claim arising from a continuing wrong, a party could, theoretically, delay filing suit indefinitely."). We decline to reach such a result here.
[1]: https://www.law.cornell.edu/uscode/text/17/507
Posted Aug 8, 2023 11:43 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
Thanks for that, but for purposes of my own understanding, how is this current scenario materially different from the delays from initial infringement-to-enforcement in SCO v IBM (which I think is _still_ not quite technically over) and more recently, Oracle v Google? Ultimately both were more about ongoing infringement, no?
The SCO debacle in particular is where the Linux kernel's Developer Certificate of Origin came from, and I think it's safe to state that, regardless of any technical/stylistic/etc issues, there's no way [Open]ZFS would ever get accepted into the mainline without "signed-off-by: legal@oragle.com" or shipping [Open]ZFS binaries as part of OracleLinux.
Posted Aug 8, 2023 14:53 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Firstly, it's very easy to sue in the US even when you have no case.
Secondly, certainly in the SCOG case we think the initial aim was to get IBM to buy them off, and then (for SCOG) it turned into an existential fight for survival plus a fraud to milk the company. So they were simply prolonging the case any which way they could.
And then, when you really have a case, it gets summarily dismissed (WP vs MS) - based on a mis-direction by a Judge I believe. WordPerfect thought that the statute of limitations had been stayed by Netscape vs MS, only to discover when they tried to litigate using Netscape as precedent, that it hadn't and they were out of time. I think what they *should* have done was launch the suit and at the same time ask the Judge to stay the case until NS vs MS was over. But either counsel misled them, or they mis-understood counsel.
Cheers,
Posted Aug 10, 2023 0:37 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
Posted Aug 6, 2023 17:16 UTC (Sun)
by DemiMarie (subscriber, #164188)
[Link]
Posted Aug 5, 2023 9:01 UTC (Sat)
by snajpa (subscriber, #73467)
[Link]
In case you haven't noticed, OpenZFS does not focus on a single kernel; integrating with Linux is not happening, as it isn't the project's goal. Which also makes for +1 argument that it is _not_ a derivative work of Linux. It was developed independently and while Linux was the only kernel for a while, now there are two, FreeBSD and Linux - and support for more is coming.
I guess some really, really envy what OpenZFS can do and Linux can't? But this vitriol is not the way how to persuade people to abandon working on OpenZFS and make them see the light and go re-develop it from scratch for Linux. If anything, it'll make us double down working on OpenZFS. As a cherry on top, one doesn't have to deal with the awful dev experience that the LKML brings :-D
Posted Aug 5, 2023 7:59 UTC (Sat)
by snajpa (subscriber, #73467)
[Link] (1 responses)
Posted Aug 5, 2023 8:13 UTC (Sat)
by snajpa (subscriber, #73467)
[Link]
Posted Aug 5, 2023 7:51 UTC (Sat)
by snajpa (subscriber, #73467)
[Link] (6 responses)
Posted Aug 5, 2023 11:40 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link] (5 responses)
Sure it's always possible, but it's a pain in field. I used to have highly patched kernels for a few decades, starting with ip_masq patches + IDE hotplug patches on top of kernel 1.2.13, VM+ipchains+NFS patches in 2.0, 2.1-ac on production servers, then 2.2+vlan+knfsd+raid+reiseirfs+FSACL on many servers including at customers, I can assure you one thing: from this point I started to slow down on patched kernels, especially when it comes to my data. I remember having to borrow a SIMM DRAM at work one evening to try to fsck my out-of-tree FS running on top of out-of-tree RAID over an out-of-tree SCSI driver. You don't feel very proud of you until you see fsck complete successfully! I've later run 2.4 with loop-aes and many other patches (~200 total), but this time not on critical data. Loop-aes was only used to protect customer's traces on my laptop.
From this era I decided not to use any out-of-tree stuff to store my data: hardware drivers, block layout, file system, etc. It's far too painful, you're not free to upgrade your kernel when you want, and whatever kernel you want to try requires to first apply all the mandatory patches you're relying on, and to fix rejects by hand. I've done that for 20 years and consider it's not worth the effort and the hassle. Filesystems are pretty good nowadays, I wouldn't value the ZFS improvements enough to experience this trouble anymore. By then in 2.2, there was a motivation to patch for reiserfs, it was the first usable journaled FS which didn't require 20 minutes of fsck at boot after a kernel panic or a power outage. Now ext4 is pretty good for general use and small files in general, XFS is good on large files, btrfs is reasonably balanced and has more features. That's sufficient to me. I'll wait for ZFS to reach mainline to try it.
Posted Aug 5, 2023 12:18 UTC (Sat)
by snajpa (subscriber, #73467)
[Link] (4 responses)
We're forced to do our own thing since OpenVZ guys went fully their distro-only way and it's now less transparent to an outsider; we started as a kind of community-run hosting for members in 2009; now we run vanilla with custom patches for special treatment of the 1st level user-ns, syslog ns and a few other things to make it closer to full-VM experience; but unlike OpenVZ being RH-cenric based, we compose it with Nix/nixpkgs into our own live-OS release. I just painted it too rosey about being able to contribute our changes back, we'd need to double the community in size to be able to afford more devs :D and now with the inflation... crazy times :D
Posted Aug 6, 2023 4:19 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link] (3 responses)
It's not a matter of trust. Any FS may fail, and any system may fail to boot due to manipulation errors or FS corruption, and the day it fails you need to know how you can recover your data when your server is sick. It's where there is a big difference between booting the server from a random distro's USB stick and copy all the data over night onto a USB external drive, and having to go through the complex hoops of building the kernel that supports your FS from another machine (possibly someone else's when it's your dev machine that died). If you know that regular distros include support for your FS on the default boot images, that could be OK. Otherwise it's really a pain.
Posted Aug 6, 2023 11:50 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 6, 2023 14:18 UTC (Sun)
by cyphar (subscriber, #110703)
[Link] (1 responses)
I highly doubt this will ever stop being the case. But even if that does happen, because ZFS is multi-platform you can always use FreeBSD or Illinois in a pinch. The same cannot be said for most of Linux's filesystems.
Posted Aug 10, 2023 13:22 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Posted Aug 10, 2023 12:49 UTC (Thu)
by net_benji (subscriber, #75195)
[Link]
Maybe it's pedantic but I would say that Christoph Hellwig *submitted* that patch. It was *merged* to mainline Linux by other people.
Posted Aug 28, 2023 13:34 UTC (Mon)
by irvingleonard (guest, #156786)
[Link] (3 responses)
Posted Aug 28, 2023 14:09 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Interoperability with the typical DRM-protected resource is illegal (according to the US-based DMCA at least, probably effectively exported to elsewhere via treaties by this point). There are some exceptions, but they are subject to change every 3 years by the Library of Congress (and also subject to lobbying efforts).
Posted Aug 28, 2023 16:00 UTC (Mon)
by mb (subscriber, #50428)
[Link] (1 responses)
It's by far not that well-defined.
Posted Aug 28, 2023 18:32 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
It's full of assumptions as to what a derived work is (which is a matter for the law, not the GPL).
It's full of assumptions as to what is copyrightable subject matter (which again is the law, not the GPL).
The GPL is only clear when you're talking about statically linked binaries, which are rare as hens teeth on linux ...
And although my favourite system (Scarlet) is GPL, if I tried to use the GPL try to to stop people shipping systems chock full of binaries, with only the publically available source made available to the customer, I'd probably be on an extremely sticky wicket ...
Oh, and what happens if I build my own kernels (which I do, I run gentoo). All these (allegedly) proprietary modules which the kernel refuses to run, they CAN'T be GPL violations, because it was me that created the binary, and it's me running the binary, so the GPL doesn't apply.
Cheers,
Making life (even) harder for proprietary modules
MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");
Making life (even) harder for proprietary modules
@mtu.edu
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Wol
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
[2] Keyboard, Mouse, USB hubs, card readers/memory sticks/memory cards, USB speaker, both displays, webcam, and so on.
[3] CPU, Display controller, ethernet & wifi controllers, and maybe more.
[4] As in without said proprietary firmware they're useful only as paperweights. If even that.
[5] ie AMD and Intel, which have been using this "open mainline driver that talks to highly proprietary firmware" approach for the better part of two decades.
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Netgpu and the GPL
Netgpu and the GPL
2. If it infringes NVIDIA's copyright, then it arguably(!) offends this passage of the GPL, particularly the final sentence:
Netgpu and the GPL
3. If NVIDIA *has* given permission to create this sort of thing (e.g. in their EULA), then the fact that it's being done by Facebook and not NVIDIA is immaterial. NVIDIA could just as easily do it themselves.
Netgpu and the GPL
Netgpu and the GPL
Netgpu and the GPL
Wol
Create a loop-around internal pipe(), run kallsysms and direct the output into the pipe, read the pipe, parse the address and symbol name, call by pointer. Takes around one second or less.
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
It is a waste of effort for developers to spend time finding license backdoors.
Making life (even) harder for proprietary modules
How much does Oracle Linux compete with non-Linux OSes, and how much is it in a space where we've won?
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
And Oracle Linux has no USP over other Linux distributions, except that you can get support from the same company that supports your database if you're unfortunate enough to have an Oracle database.
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
>
> For similar reasons, we reject McClory's argument that laches may never bar a claim for infringement brought within the statute of limitations. We have already determined that laches may sometimes bar a statutorily timely claim. Kling, 225 F.3d at 1039; Jackson, 25 F.3d at 888. And, although such an application of laches may be unusual, see Telink, 24 F.3d at 45 n. 3, it is appropriate here. Even leaving aside the special circumstance of re-releases, we conclude in any event that McClory's extraordinary delay and the extraordinary prejudice to Danjaq render laches appropriate despite the statute of limitations. Id. at 46 n. 5 ("If the defendant can show harm from the delay, the court may, in extraordinary circumstances, defeat the claim based on laches, though the claim is within the analogous limitations period.").
[2]: https://casetext.com/case/danjaq-llc-v-sony-corporation
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Wol
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
Making life (even) harder for proprietary modules
It's rather that some developer had the opinion that using a certain symbol would surely be a GPL violation. That is not well-defined at all.
Making life (even) harder for proprietary modules
Wol