linux-kernel - What is an objtool recipe to solve the unpatched kernel thunk warnings in out-of-tree modules?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <PH7PR11MB6523524C9B34ACA312FB0148A9AD2@PH7PR11MB6523.namprd11.prod.outlook.com>
Date: Fri, 19 Jul 2024 18:07:28 +0000
From: "Preble, Adam C" <adam.c.preble@...el.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: What is an objtool recipe to solve the unpatched kernel thunk
 warnings in out-of-tree modules?

We've seen some of those "Unpatched return thunk in use. This should not happen!" warnings in some out-of-tree code and I'm trying to figure out how to modify the binaries instead of just disabling CONFIG_MITIGATIONS_RETHUNK. I've looked at a few recent commits going back to April where some fixes were done in-tree and followed some of the QEMU conversations over the same warning. It sounds like I need to look at how objtool is munging my generated code.

A common fix I've seen was to strip OBJECT_FILES_NON_STANDARD_[some object here] clauses from Makefiles. As I understand it, their existence suppresses objtool from running on the files. I could set OBJECT_FILES_NON_STANDARD to 'y' and just completely shut off objtool, but I want the opposite. I didn't have any of those in the first place. For giggles, I tried setting it to 'n' explicitly, but that didn't help. I'm not surprised since I expect that's the default.

Failing having anything else I've explicitly done, I figure I should just paste what objtool currently is doing with each module:

./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --retpoline --rethunk --stackval --static-call --uaccess --prefix=16   --module [path to .o here]

Does anything look amiss?

There could be an X-instead-of-Y here with my objtool fascination. Other threads seemed to steer this way. I'd rather be specific, find out that was a misunderstanding, and perish that thought first instead of going a few rounds over a more general approach where objtool nags at me.

[PS I'd also gobble up any summaries on all of these workarounds for various side-channel speculation attacks because they bite me from time to time and I need to level up on them]