linux-kernel - Re: [RFC] Circumventing FineIBT Via Entrypoints

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

Message-ID: <qczypdkenk2e5atbn46o2xhts6vtu2hxvmucvhkuu7zoziuq2c@26tyi763snot>
Date: Fri, 14 Feb 2025 14:25:28 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Jennifer Miller <jmill@....edu>, Andy Lutomirski <luto@...nel.org>, 
	linux-hardening@...r.kernel.org, kees@...nel.org, joao@...rdrivepizza.com, 
	samitolvanen@...gle.com, kernel list <linux-kernel@...r.kernel.org>, 
	Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

On Thu, Feb 13, 2025 at 08:23:34PM +0100, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 7:15 AM Jennifer Miller <jmill@....edu> wrote:
> > In short, we could have the slowpath branch as you suggested, in the
> > slowpath permit the stack switch and preserving of the registers on the
> > stack, but then do a sanity check according to the __per_cpu_offset array
> > and decide from there whether we should continue executing the entrypoint
> > or die/attempt to recover.
> 
> One ugly option to avoid the register spilling might be to say
> "userspace is not allowed to execute a SYSCALL instruction while RSP
> is a kernel address, and if userspace does it anyway, the kernel can
> kill the process". Then the slowpath could immediately start using the
> GPRs without having to worry about where to save their old values, and
> it could read the correct gsbase with the GET_PERCPU_BASE macro. It
> would be an ABI change, but one that is probably fairly unlikely to
> actually break stuff? But it would require a bit of extra kernel code
> on the slowpath, which is kinda annoying...

Could all this be made easier if we went back to having percpu entry
trampolines?  Then the trampoline could just use a PC-relative access to
get the kernel stack pointer without needing %gs.

I think the main reason the entry trampolines were removed was because
they needed an indirect branch to jump back to the global text.  But
they could be allocated within 2GB of the entry text and do a direct
jump.

-- 
Josh