From: Rudolf Marek <r.marek@assembler.cz>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jann Horn <jannh@google.com>
Cc: jmill@asu.edu, joao@overdrivepizza.com, luto@kernel.org,
samitolvanen@google.com,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
linux-hardening@vger.kernel.org,
lkml <linux-kernel@vger.kernel.org>,
x86 maintainers <x86@kernel.org>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints
Date: Wed, 26 Feb 2025 23:48:14 +0100 [thread overview]
Message-ID: <73ef8000-661e-47b4-a8b0-a02d3a849645@assembler.cz> (raw)
In-Reply-To: <8b82b394-3f54-437b-bd3a-7ac0eabda687@citrix.com>
Hi Andrew,
Dne 25. 02. 25 v 22:14 Andrew Cooper napsal(a):
> As stand-in for "the reader", I'll point out that you need to add #DB to
> that list or you're in for a rude surprise when running the x86 selftests.
Thanks for pointing this out. I forgot about the interrupt shadow on SYSCALL
and possibly some breakpoints possibilities in the kernel.
>> The SYSCALL/SYSENTER startup has interrupts disabled, so it is the
>> problem of NMI/#MC
>> handler which would need deal with the normal case and attack case.
>
> Right, but in the case of the attack, regular interrupts are most likely
> enabled too. And writing this has just caused me to realise a
> yet-more-fun case.
> An interrupt hitting the syscall entry path (prior to SWAPGS) will cause
> the interrupt handler's CPL check and conditional SWAPGS to do the wrong
> thing and switch onto the user GS base too. (Prior research e.g.
> GhostRace has shown how to get an hrtimer to reliably hit an instruction
> boundary.)
I don't see it, because if attacker starts at syscall entry and interrupts are
enabled and the interrupt happens right there the handler will just see proper
IRET frame with %cs of kernel and will not perform swapgs. I will try to think
about it again tomorrow I likely missed something.
> Interrupts and exceptions look at %cs in the IRET frame to judge whether
> to SWAPGS or not (and this is one of the main things that paranoid_entry
> does differently). In the case of the attack, there's no IRET frame
> pushed on the stack and the read of %cs is out-of-bounds, most likely
> the stack frame of the function which followed the corrupt function pointer.
Thank you for your detailed explanation.
> The SYSCALL entrypoint is simply the easiest to pivot on, but all can be
> attacked in this manner. Fixing only the SYSCALL entrypoint doesn't
> improve things much.
Maybe more elegant and cheap check on IDT entry "authenticity" would be to check
for current %ss which needs to be NULL and possibly check the %CS on stack frame
by checking kernel %cs and not just two CPL bits and/or perform more checks.
Another ideas if you think it is still worth to discuss this topic:
What about to use completely different %CS selector for all entry code? The
early entry code would check the %cs selector and panic if it is wrong one.
After swapgs dance, we need to perform far jump to normal kernel %CS, which
might cost something.
To fix the interrupt on fake entry problem, we could check in relevant IDT
handlers that we never come from "completely different" %CS used above for the
early entry code.
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.
Thanks,
Rudolf
next prev parent reply other threads:[~2025-02-26 22:48 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Z60NwR4w/28Z7XUa@ubun>
2025-02-12 22:29 ` Jann Horn
2025-02-13 1:31 ` Andrew Cooper
2025-02-13 2:09 ` Jann Horn
2025-02-13 2:42 ` Andrew Cooper
2025-02-22 20:43 ` Rudolf Marek
2025-02-25 18:10 ` Andrew Cooper
2025-02-25 20:06 ` Rudolf Marek
2025-02-25 21:14 ` Andrew Cooper
2025-02-26 2:55 ` Kees Cook
2025-02-26 22:48 ` Rudolf Marek [this message]
2025-02-27 0:41 ` Andrew Cooper
2025-03-01 22:48 ` Rudolf Marek
2025-03-02 19:16 ` Rudolf Marek
2025-03-02 22:31 ` Andrew Cooper
2025-02-28 12:13 ` Florian Weimer
2025-02-13 20:28 ` Kees Cook
2025-02-13 20:41 ` Andrew Cooper
2025-02-13 20:53 ` Kees Cook
2025-02-13 20:57 ` Jann Horn
2025-02-16 23:42 ` Kees Cook
2025-02-14 9:57 ` Peter Zijlstra
2025-02-15 21:07 ` Peter Zijlstra
2025-02-16 23:51 ` Kees Cook
2025-02-17 10:39 ` Peter Zijlstra
2025-02-17 13:06 ` David Laight
2025-02-17 13:13 ` Peter Zijlstra
2025-02-17 18:38 ` David Laight
2025-02-17 18:54 ` Peter Zijlstra
2025-02-14 10:05 ` Peter Zijlstra
2025-02-14 9:54 ` Peter Zijlstra
2025-02-13 6:15 ` Jennifer Miller
2025-02-13 19:23 ` Jann Horn
2025-02-13 21:24 ` Andrew Cooper
2025-02-13 23:24 ` Jennifer Miller
2025-02-13 23:43 ` Jann Horn
2025-02-14 23:06 ` Andrew Cooper
2025-02-15 0:07 ` Jennifer Miller
2025-02-15 0:11 ` Andrew Cooper
2025-02-15 0:19 ` Jennifer Miller
2025-02-14 22:25 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73ef8000-661e-47b4-a8b0-a02d3a849645@assembler.cz \
--to=r.marek@assembler.cz \
--cc=andrew.cooper3@citrix.com \
--cc=jannh@google.com \
--cc=jmill@asu.edu \
--cc=joao@overdrivepizza.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=samitolvanen@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®