LWN: Comments on "Indirect branch tracking for Intel CPUs"

Indirect branch tracking for Intel CPUs

josephcsible — Fri, 05 Aug 2022 16:26:57 +0000

I stand corrected: it turns out that the Linux kernel sets NOTRACK_EN=0, which makes that prefix ineffective. I wonder whether a similar goal could be accomplished by using the shadow stack manipulation instructions and then doing what's basically a retpoline, though.

Indirect branch tracking for Intel CPUs

josephcsible — Thu, 16 Jun 2022 01:50:42 +0000

> It is a common technique for proprietary modules to look up the non-exported functions they need in the kernel's symbol table, then call them via an indirect branch, thus bypassing the kernel's limitations. But, with IBT enabled, any function lacking an endbr instruction will no longer be callable in this way.

This won't stop that. An indirect branch instruction can have a NOTRACK prefix, which suppresses IBT for just that one branch. The proprietary modules will just start using that prefix on their branches, and they can carry on just as before.

Indirect branch tracking for Intel CPUs

calumapplepie — Tue, 12 Apr 2022 04:20:52 +0000

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

flussence — Mon, 11 Apr 2022 15:14:45 +0000

> 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.

Indirect branch tracking for Intel CPUs

anselm — Mon, 11 Apr 2022 14:04:54 +0000

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

LtWorf — Mon, 11 Apr 2022 11:09:46 +0000

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

immibis — Fri, 08 Apr 2022 14:29:21 +0000

That's what the AGPL is for

Indirect branch tracking for Intel CPUs

kronat — Fri, 08 Apr 2022 14:10:53 +0000

> 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

nybble41 — Thu, 07 Apr 2022 16:04:31 +0000

> 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

Wol — Thu, 07 Apr 2022 15:22:34 +0000

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

sfeam — Thu, 07 Apr 2022 00:28:46 +0000

"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

immibis — Wed, 06 Apr 2022 23:21:11 +0000

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

nybble41 — Wed, 06 Apr 2022 18:04:40 +0000

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

immibis — Wed, 06 Apr 2022 16:34:19 +0000

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

immibis — Wed, 06 Apr 2022 16:32:13 +0000

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

developer122 — Sat, 02 Apr 2022 01:45:27 +0000

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

jamescrake-merani — Fri, 01 Apr 2022 10:28:20 +0000

Probably in the hope that one of the revisions will actually get noticed. But personally that hope would be running very thin if I were doing that.

Indirect branch tracking for Intel CPUs

andy_shev — Fri, 01 Apr 2022 09:46:06 +0000

What does motivates the author to send 30 versions if no getting any comments?

Indirect branch tracking for Intel CPUs

Villemoes — Fri, 01 Apr 2022 07:35:44 +0000

> For example, the kernel gained support for a compiler-implemented IBT mechanism during the 5.13 development cycle. In this mode, the compiler routes every indirect branch through a "jump table", ensuring that the target is not only meant to be reached by indirect branches, but that the prototype of the called function matches what the caller is expecting. This approach works, at the cost of a fair amount of compile-time and run-time overhead.

That mechanism also proactively prevents attackers from gaining control over the machine by inducing NULL pointer derefs (and who knows what other malfunctions) in perfectly fine C code. If you consider enabling that, make sure none of the code included in your build relies on function pointer (in)equality testing.

Indirect branch tracking for Intel CPUs

donald.buczek — Fri, 01 Apr 2022 04:56:50 +0000

Good question. It looks like Make Linux Fast Again benchmarks find only 2% gain (10% maximum on some specific tests) and that you don't perceive a difference during normal interactive usage outside of benchmarks. [1] [2] [...]

[1]: https://wonky.computer/post/make-linux-fast-again/
[2]: https://www.linux-community.de/ausgaben/linuxuser/2019/08... (german)

Indirect branch tracking for Intel CPUs

milesrout — Fri, 01 Apr 2022 04:02:21 +0000

I often wonder how much faster my system would be if *all* of these layers upon layers of security mitigations were removed. Would it be 10% faster? 30% faster? All to protect against security issues that almost always come down to running untrusted code on my machine or something to do with web browsers.

Indirect branch tracking for Intel CPUs

donald.buczek — Thu, 31 Mar 2022 20:25:49 +0000

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...

Loadable kernel modules could be vetted

Sesse — Thu, 31 Mar 2022 19:49:24 +0000

While it's at it, perhaps it could check for the HLT opcode on a taken path… =)

Loadable kernel modules could be vetted

sdalley — Thu, 31 Mar 2022 19:02:12 +0000

Maybe the kernel module loader could check for any such IBT-fiddling instruction opcodes before permitting the load?

Indirect branch tracking for Intel CPUs

mb — Thu, 31 Mar 2022 18:28:14 +0000

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

JoeBuck — Thu, 31 Mar 2022 18:19:01 +0000

Seems that would be a blatant DMCA violation in the US (distributing a mechanism to bypass copyright protection), though perhaps it would be considered against the spirit of free software for the kernel developers to enforce that?

Indirect branch tracking for Intel CPUs

Hello71 — Thu, 31 Mar 2022 16:35:13 +0000

> As Peter Zijlstra pointed out, there is another, perhaps surprising advantage to removing the unneeded endbr instructions. The kernel limits the functions that are available to loadable modules, and proprietary modules are limited even further. It is a common technique for proprietary modules to look up the non-exported functions they need in the kernel's symbol table, then call them via an indirect branch, thus bypassing the kernel's limitations. But, with IBT enabled, any function lacking an endbr instruction will no longer be callable in this way.

Why can't the crap module simply turn off IBT before calling the function (and hopefully turn it back on afterwards)?