Indirect branch tracking for Intel CPUs

Posted Mar 31, 2022 18:28 UTC (Thu) by mb (subscriber, #50428)
In reply to: Indirect branch tracking for Intel CPUs by JoeBuck
Parent article: Indirect branch tracking for Intel CPUs

If that's the case, then

func = kallsym_lookup_name("unexported_function");
(*func)(args);

would also be a DMCA violation already.

The hypothesis was: IBT could to be used to technically prevent the illegal kallsym_lookup_name.
But can it prevent it?

Indirect branch tracking for Intel CPUs

Posted Mar 31, 2022 20:25 UTC (Thu) by donald.buczek (subscriber, #112892) [Link] (2 responses)

I think, kallsym_lookup_name itself is no longer exported. But you can work around that, too.

There are legitimate reasons to call a non-exported kernel function from a module. E.g. when you create a module to install a ftrace-based wrapper around a kernel function with a security problem because you can't immediately reboot into a fixed kernel for one reason or another and you are not prepared for live patching.

We recently had to do that [1] and needed to work around a missing kallsym_lookup_name, which we did with register_kprobe.

The attempt of the kernel to restrict modules reminds me of DRM. You don't really succeed, bad guys work around anyway, but you make life harder for legitimate users.

[1]: https://github.molgen.mpg.de/mariux64/fix-lpp/blob/main/f...

Indirect branch tracking for Intel CPUs

Posted Apr 2, 2022 1:45 UTC (Sat) by developer122 (guest, #152928) [Link] (1 responses)

On philosophical grounds I also half-object to the indifference about what licence that code is under. There's no love for fellow copyleft brethren who aren't specifically GPL. (despite Torvalds' insistence on getting changes back being his real only aim)

Half-object because there would be *some* maintenance burden to making changes for out of tree code. The kernel already has to periodically sync against other upstream projects whose code it uses.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 16:34 UTC (Wed) by immibis (subscriber, #105511) [Link]

All derivative works of the kernel must be GPLv2 - that's how the GPL works. AFAIK Linus's opinion is that if you only use non-GPL-marked exported functions - functions you might expect to find in any kernel - then your module is not a derivative work of Linux in particular, but GPL exports are functions that are sufficiently entangled with Linux in particular that you can't reasonably claim your driver is not derived from Linux.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 16:32 UTC (Wed) by immibis (subscriber, #105511) [Link] (11 responses)

Aren't they already in violation of copyright by being non-GPL derivative works of the kernel?

I believe common opinion is settled: exported functions form an arms-length public API, but if you go digging in deeply, you're a derivative work. Of course, that has not been tested in court.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 18:04 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (10 responses)

A program that references a function or variable from some other software is no more a "derivative work" of that external code than a research paper is a "derivative work" of all the other papers cited in its bibliography.

From 17 U.S.C. § 101 <http://www.copyright.gov/title17/92chap1.html#101>:

> A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.

What all the examples have in common is that they actually incorporate the original work—not just a reference but the actual creative expression in some form or another—as part of the derivative work. Source code or dynamically linked object code which merely *references* some external API is not a "recast, transformed, or adapted" version of that other software in the form in which it is distributed and does not resemble any of the examples given here.

I am not your lawyer, this is not legal advice, yada yada, but IMHO the idea that your original loadable kernel module should be treated as a derivative work of the kernel just because it *references* certain kernel APIs by name is completely without basis under any reasonable interpretation of US copyright law.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 23:21 UTC (Wed) by immibis (subscriber, #105511) [Link] (9 responses)

Cool, then dynamic linking does not create a derivative work and the GPL is pointless. Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 0:28 UTC (Thu) by sfeam (subscriber, #2841) [Link] (5 responses)

"dynamic linking does not create a derivative work" - probably correct, but argued about endlessly.

"and the GPL is pointless" - Maybe you meant the LGPL? In which case I agree with you; the LGPL is in essence identical to the GPL with the addition of a promise not to get into the above endless argument.

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 15:22 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Question: Do the library header files contain a non-trivial amount of in-line code ...

Cue endless bikeshedding about the meaning of "non-trivial" :-)

Cheers,
Wol

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 16:04 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> Do the library header files contain a non-trivial amount of in-line code ...

a) Non-trivial code shouldn't be inlined. b) This has no bearing on the question of "GPL-only" kernel symbols as inline code isn't accessed through the symbol table. c) Inline code in headers files would have no effect on modules distributed in source form (including obfuscated source), as the source distribution doesn't include those headers. d) If the inclusion of certain nontrivial inline code is required for the interoperability for a binary module distribution this could reasonably be argued to be fair use.

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 11:09 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

Dynamic linking is static after the linking has happened.

Like there is a statically linked file on disk, there is a statically linked file in RAM.

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 14:04 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

Dynamic linking is static after the linking has happened.

Yes, but the result isn't distributed to others, so copyright doesn't kick in. FWIW, the GPL explicitly says that, on your own machine, you get to do whatever you want with the code, which would presumably include dynamically linking stuff to it.

IOW, I'm perfectly free to take my own copy of Harry Potter and replace all occurrences of “Albus Dumbledore” with “Alfred E. Newman”. As long as I don't distribute the result to anybody else, the fact that this has created a “derived work” of the original book is of concern to nobody except myself.

Indirect branch tracking for Intel CPUs

Posted Apr 12, 2022 4:20 UTC (Tue) by calumapplepie (guest, #143655) [Link]

Actually, assuming you mean a physical book, it's totally fine for you to take that edited version and sell it. You own the book, after all: the author got her cut, and the publisher theirs. Trademark law MIGHT get involved, but as far as copyright is concerned, since you aren't diluting the market of the original, you're golden.

Indirect branch tracking for Intel CPUs

Posted Apr 8, 2022 14:10 UTC (Fri) by kronat (subscriber, #117266) [Link] (1 responses)

> Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

s/separate files/in the cloud, and problem solved, without caring about linking.

Indirect branch tracking for Intel CPUs

Posted Apr 8, 2022 14:29 UTC (Fri) by immibis (subscriber, #105511) [Link]

That's what the AGPL is for

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 15:14 UTC (Mon) by flussence (guest, #85566) [Link]

> Cool, then dynamic linking does not create a derivative work and the GPL is pointless. Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

I think Microsoft would vastly prefer the opposite to be true, given that they could've sued Wine users out of existence for using their ABIs if it were.