linux-hardening - Re: [PATCH] x86/alternatives: Make FineIBT mode Kconfig selectable

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202407291720.1E1B193A@keescook>
Date: Mon, 29 Jul 2024 17:41:34 -0700
From: Kees Cook <kees@...nel.org>
To: jvoisin <julien.voisin@...tri.org>
Cc: ast@...nel.org, bp@...en8.de, dave.hansen@...ux.intel.com,
	hpa@...or.com, jgross@...e.com, jpoimboe@...nel.org,
	leitao@...ian.org, linux-hardening@...r.kernel.org,
	linux-kernel@...r.kernel.org, mingo@...hat.com, nathan@...nel.org,
	peterz@...radead.org, samitolvanen@...gle.com, tglx@...utronix.de,
	x86@...nel.org
Subject: Re: [PATCH] x86/alternatives: Make FineIBT mode Kconfig selectable

On Mon, Jul 29, 2024 at 02:35:02PM +0200, jvoisin wrote:
> > Since FineIBT performs checking at the destination, it is weaker against
> > attacks that can construct arbitrary executable memory contents. As such,
> > some system builders want to run with FineIBT disabled by default. Allow
> > the "cfi=kcfi" boot param mode to be selectable through Kconfig via the
> > newly introduced CONFIG_CFI_AUTO_DEFAULT.
> 
> I'm confused as why you think that KCFI is stronger/better than FineIBT.

Sure, can I try to explain this more.

> The latter is compatible with execute-only memory,

Yes, and since Linux doesn't have kernel execute-only memory (and likely
won't for some time), it doesn't make sense to use FineIBT over KCFI for
that reason.

> makes use of hardware support,

Hm? KCFI does too. IBT is still enabled with KCFI (when the hardware
supports it).

> doesn't need LTO,

KCFI doesn't need LTO either.

> is faster,

What? Measured how? I feel like you're thinking about the old Clang CFI,
not the modern KCFI implementation.

> … moreover, I don't see why an
> attacker able to "construct arbitrary executable memory contents"
> wouldn't be able to bypass KCFI as well,

To bypass KCFI, the attacker additionally needs a targeted memory
exposure to get the correct function hash that they must include before
the malicious function they construct. With FineIBT, no such exposure is
needed.

> since its threat model
> (https://github.com/kcfi/docs/blob/master/kCFI_whitepaper.pdf)
> explicitly says "We assume an OS that fully implements the W^X policy
> [56,58,106] preventing direct code injection in kernel space."

I mean, a whitepaper's threat model is nice and all, but this just isn't
the reality. Linux certainly tries to maintain W^X, but there are bugs
and things like BPF, which can be manipulated to gain attacker-controlled
executable code injected into the kernel address space. (e.g. BPF will
flip a writable region from RW to RX, so W^X is maintained spatially but
not temporally.)

So without execute-only memory, some deployments prefer to not weaken
the CFI implementation to allow for hash checking bypasses. Once X-O
exists, FineIBT is a slam-dunk over KCFI. :)

-Kees

-- 
Kees Cook