[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250904071601.GY4067720@noisy.programming.kicks-ass.net>
Date: Thu, 4 Sep 2025 09:16:01 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <kees@...nel.org>
Cc: Qing Zhao <qing.zhao@...cle.com>,
"gcc-patches@....gnu.org" <gcc-patches@....gnu.org>,
Joseph Myers <josmyers@...hat.com>,
Richard Biener <rguenther@...e.de>, Jan Hubicka <hubicka@....cz>,
Richard Earnshaw <richard.earnshaw@....com>,
Richard Sandiford <richard.sandiford@....com>,
Marcus Shawcroft <marcus.shawcroft@....com>,
Kyrylo Tkachov <kyrylo.tkachov@....com>,
Kito Cheng <kito.cheng@...il.com>,
Palmer Dabbelt <palmer@...belt.com>,
Andrew Waterman <andrew@...ive.com>,
Jim Wilson <jim.wilson.gcc@...il.com>,
Dan Li <ashimida.1990@...il.com>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity
infrastructure
On Wed, Sep 03, 2025 at 09:24:22PM -0700, Kees Cook wrote:
> > If the hacker knows these, it should be quite easy for them to come up with a
> > matched typeid, is it?
>
> The hashes aren't considered secret -- they need to be known/match between
> compilation units, and even across languages (Rust). The KCFI mitigation
> is fundamentally an "exploit surface reduction" measure in the sense
> that it limits an attacker's set of callable functions to only matching
> typeids (instead of all functions or all executable memory). I discuss
> this a big more here:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693059.html
Also note that the kernel with re-hash all the values at boot time once
more -- further increasing the difficulty of an attack.
Powered by blists - more mailing lists