Messages in this thread | | | Date | Tue, 18 Oct 2022 22:00:08 -0700 | From | Kees Cook <> | Subject | Re: [PATCH] x86/ibt: Implement FineIBT |
| |
On Tue, Oct 18, 2022 at 10:05:03PM +0200, Peter Zijlstra wrote: > On Tue, Oct 18, 2022 at 11:09:13AM -0700, Kees Cook wrote: > > I still think it's worth noting it does technically weaken the > > "attacker-controlled executable memory content injection" attack > > requirements, too. While an attacker needs to make sure they place an > > ENDBR at the start of their injected code, they no longer need to also > > learn and inject the CFI hash too, as the malicious code can just not > > do the check at all. The difference in protection currently isn't much. > > Hmm, true; although I do feel that the moment attackers can write code > we might be having worse problems.
Totally agreed! :) But this is why I've wanted to keep a bright line between "kernel area", "modules area" and "everything else", in the hopes that we can use other things like PKS to block the "everything else" area, but one thing at a time.
> > > It's not a very difficult requirement to get attacker-controlled bytes > > into executable memory, as there are already existing APIs that provide > > this to varying degrees of reachability, utility, and discoverability -- > > for example, BPF JIT when constant blinding isn't enabled (the unfortunate > > default). > > BPF has another problem in that the current control transfer to BPF > progs is nocfi. At the very least we can have them have a hash, no?
Yup, it's on the list.
-- Kees Cook
| |