On Tue, Nov 23, 2021 at 10:58:57AM +0100, Miroslav Benes wrote: > [ 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? The problem was bpf, and probably still is. I've not come around to looking at it. Asusming fentry is at +0 is silly (although I would like to see that restored for other reasons), but bpf will also need to emit ENDBR at least at the start of every JIT'ed program, because entry into them is through an indirect branch. If nobody beats me to it, I'll get around to it eventually.
