[ adding more CCs ] On Mon, 22 Nov 2021, joao@xxxxxxxxxxxxxxxxxx wrote: > Hi Miroslav, Petr and Nicolai, > > Long time no talk, I hope you are all still doing great :) Everything great here :) > So, we have been cooking a few patches for enabling Intel CET/IBT support in > the kernel. The way IBT works is -- whenever you have an indirect branch, the > control-flow must land in an endbr instruction. The idea is to constrain > control-flow in a way to make it harder for attackers to achieve meaningful > computation through pointer/memory corruption (as in, an attacker that can > corrupt a function pointer by exploiting a memory corruption bug won't be able > to execute whatever piece of code, being restricted to jump into endbr > instructions). To make the allowed control-flow graph more restrict, we are > looking into how to minimize the number of endbrs in the final kernel binary > -- meaning that if a function is never called indirectly, it shouldn't have an > endbr instruction, thus increasing the security guarantees of the hardware > feature. > > Some ref about what is going on -- > https://lore.kernel.org/lkml/20211122170805.149482391@xxxxxxxxxxxxx/T/ Yes, I noticed something was happening again. There was a thread on this in February https://lore.kernel.org/all/20210207104022.GA32127@xxxxxxx/ and some concerns were raised back then around fentry and int3 patching if I remember correctly. Is this still an issue? > IIRC, live-patching used kallsyms/kallsyms_lookup_name for grabbing pointers > to the symbols in the running kernel and then used these pointers to invoke > the functions which reside outside of the live-patch (ie. previously existing > functions). With the above IBT support, if these functions were considered > non-indirectly-reachable, and were suppressed of an endbr, this would lead > into a crash. I remember we were working on klp-convert to fix this through > special relocations and that there were other proposals... but I'm not sure > where it went. > > So, would you mind giving a quick update on the general state of this? If the > IBT support would break this (and anything else) regarding live-patching... > and so on? Right. So, this really depends on how downstream consumers approach this. kpatch-build should be fine if I am not mistaken, because it uses the .klp.rela support we have in the kernel. We (at SUSE) have a problem, because we still exploit kallsyms/kallsyms_lookup_name to cope with this. Joe, what is the current state of klp-convert? Do we still want to follow that way? There was an idea a long time ago to actually rewrite all the relocations in a live patch module, so that they are relative to a well defined symbol (both in vmlinux and in modules. It would have to be created, I guess.). It would be easier tooling-wise and kernel module loader would process it like everything else. However, FGKASLR with all its reshuffling would render it useless. So something like klp-convert is needed. Thanks Miroslav
