Message-ID: <b99d222e-e65e-4865-8035-12ce889c4388@assembler.cz>
Date: Sat, 1 Mar 2025 23:48:58 +0100
From: Rudolf Marek <r.marek@...embler.cz>
To: Andrew Cooper <andrew.cooper3@...rix.com>, Jann Horn <jannh@...gle.com>
Cc: jmill@....edu, joao@...rdrivepizza.com, luto@...nel.org,
 samitolvanen@...gle.com, "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 linux-hardening@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
 x86 maintainers <x86@...nel.org>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

Hi Andrew,

Dne 27. 02. 25 v 1:41 Andrew Cooper napsal(a):
> For SYSCALL/SYSENTER it's a little more complicated.  I think you want
> to move the selectors so they don't alias __KERN_CS directly, so you can
> then move back to __KERN_CS in a similar way

Yes I thought the CHECK_CS could be right before KERN_DS so at least kernel SS 
is right.

> Give or take paranoid_entry for the IST vectors, any entrypoint that
> finds itself on __KERN_CS did not get there through the CPU loading a
> new context.

Yes

> It would depend on an attacker not being able to include a FAR CALL into
> their exploit chain, or be able toe write the IDT.  I don't know how
> reasonable that would be if we're ruling out all architectural paths not
> beginning with an ENDBR, but FAR CALLs are rare in general owing to them
> being dog slow in general, and an attacker who can write the IDT doesn't
> need these kinds of games to pivot.

In fact I wanted to use far jump, but is it OK? On 64-bit architecture, there is 
no absolute direct jump with CS change, only indirect one. Do all CPUs with 
FineIBT somehow reasonably handle all the spectre v2 and various other indirect 
branch speculation problems? To speed it up we can use "fallthrough" speculation 
to our advantage and include the target right after the instruction.

> Anyone fancy doing a prototype of this?

Maybe we can discuss following before, if you find this conversation still 
entertaining :)

1) Implement the different %cs for entry points

Looks non-trivial for an attacker to obtain right %cs before landing on the 
IDT/SYSCALL entrypoints.

Each entrypoint would check if current %cs is __KERN_CHECK_CS, and if not panic. 
Then it would change the %CS back to __KERN_CS via far jump.

I don't know how slow is to do the jump back via far jump.

2) Implement some weaker version of what I was proposing and mostly checking the 
%ss. The attacker would need to control/load %SS before jumping to endbr64 or 
provide a reasonable exception stack

SYSCALL:
- maybe do "cli" to avoid issues with interrupts/nesting
- would use valid but different %ss selector from __KERN_DS
- would check if %ss == __KERN_CHECK_DS, if not panic
- reload %SS with __KERN_DS selector

IDT entrypoints:
- maybe do "cli" to avoid issues with interrupts/nesting
- if %SS == 0, skip other checks because CPL changed (maybe too weak?)
- perform more sanity checks on exception stack maybe in a direction what I 
proposed in other email - depends if it makes attacker life miserable or not
- reload %SS with __KERN_DS selector if CPL changed (maybe needed?)

>> And very last idea would be to somehow persuade the Last Branch
>> Recording to record exception entries only and just check it from MSR.
>> But maybe it is too costly and/or not possible.
> 
> This doesn't cover all cases, I don't think.  It also won't work under
> virt, where LBR isn't reliably available.  Also LBR is reasonably full
> of errata, and quite slow.

OK thanks, it was just an idea.

Thanks,
Rudolf

Powered by blists - more mailing lists