On 02/03/2025 7:16 pm, Rudolf Marek wrote:
> Dne 01. 03. 25 v 23:48 Rudolf Marek napsal(a):
>> I don't know how slow is to do the jump back via far jump.
>
> I did some micro benchmark on Raptorlake platform using other
> operating system I'm very familiar with.
>
> I added following sequence to th
Dne 01. 03. 25 v 23:48 Rudolf Marek napsal(a):
I don't know how slow is to do the jump back via far jump.
I did some micro benchmark on Raptorlake platform using other operating system
I'm very familiar with.
I added following sequence to the SYSCALL64 entrypoint:
.balign 16
syscallentry64:
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 befor
* Andrew Cooper:
> The SYSCALL behaviour TLDR is:
>
> %rcx = %rip
> %r11 = %eflags
> %cs = fixed attr
> %ss = fixed attr
> %rip = MSR_LSTAR
>
> which means that %rcx (old rip) is the only piece of state which
> userspace can't feasibly forge (and therefore could distinguish a
>
On 26/02/2025 10:48 pm, Rudolf Marek wrote:
> 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.
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 possib
On February 25, 2025 1:14:01 PM PST, Andrew Cooper
wrote:
>Peter Zijlstra has added a FineIBT=paranoid mode which performs the hash
>check ahead of calling the function pointer, which ought to mitigate
>this but at even higher overhead.
Was kCFI vs FineIBT perf ever measured? Is the assumptio
On 25/02/2025 8:06 pm, Rudolf Marek wrote:
> Hi Andrew,
>
> Dne 25. 02. 25 v 19:10 Andrew Cooper napsal(a):
>> Very cunning. Yes it does, but the state needs to be safe to IRET back
>> to, and ...
>
> ... And intellectually very pleasing!
>
>>> Would it work to have KERNEL_CS as last entry in the
Hi Andrew,
Dne 25. 02. 25 v 19:10 Andrew Cooper napsal(a):
Very cunning. Yes it does, but the state needs to be safe to IRET back
to, and ...
... And intellectually very pleasing!
Would it work to have KERNEL_CS as last entry in the GDT table?
Therefore executing SYSCALL would set the CS as
On 22/02/2025 8:43 pm, Rudolf Marek wrote:
> Hi,
>
> Dne 13. 02. 25 v 3:42 Andrew Cooper napsal(a):
>> The SYSCALL behaviour TLDR is:
>>
>> %rcx = %rip
>> %r11 = %eflags
>> %cs = fixed attr
>> %ss = fixed attr
>> %rip = MSR_LSTAR
>>
>> which means that %rcx (old rip) is the
Hi,
Dne 13. 02. 25 v 3:42 Andrew Cooper napsal(a):
The SYSCALL behaviour TLDR is:
%rcx = %rip
%r11 = %eflags
%cs = fixed attr
%ss = fixed attr
%rip = MSR_LSTAR
which means that %rcx (old rip) is the only piece of state which
userspace can't feasibly forge (and therefor
Hey Jennifer, really cool work :)
Since you mentioned approaches to handling the issue, a possible
simple fix could be aligning function endbrs to 0x1, and keeping the
entry points at 0x0. Then, before doing the indirect call, just OR 0x1
the function address. It seems PeterZ has something else on
On Mon, Feb 17, 2025 at 06:38:27PM +, David Laight wrote:
> I may not have retpolines enabled, a typical call site is (from vmlinux.o):
Make sure CONFIG_FINEIBT=y, otherwise there is no point in talking about
this. This requires KERNEL_IBT=y RETPOLINE=y CALL_PADDING=y CFI_CLANG=y.
Then look
On Mon, 17 Feb 2025 14:13:21 +0100
Peter Zijlstra wrote:
> On Mon, Feb 17, 2025 at 01:06:29PM +, David Laight wrote:
> > On Sat, 15 Feb 2025 22:07:29 +0100
> > Peter Zijlstra wrote:
> >
> > > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb 13, 2025 at
On Sat, 15 Feb 2025 22:07:29 +0100
Peter Zijlstra wrote:
> On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> >
> > > Right, the "if they can control a function pointer" is the part I'm
> > > focusing on. This attack
On Mon, Feb 17, 2025 at 01:06:29PM +, David Laight wrote:
> On Sat, 15 Feb 2025 22:07:29 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > >
> > > > Right, the "if they ca
On Sun, Feb 16, 2025 at 03:51:27PM -0800, Kees Cook wrote:
> On Sat, Feb 15, 2025 at 10:07:29PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > >
> > > > Right, the "if they can co
On Sat, Feb 15, 2025 at 10:07:29PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> >
> > > Right, the "if they can control a function pointer" is the part I'm
> > > focusing on. This att
On Thu, Feb 13, 2025 at 09:57:37PM +0100, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 9:53 PM Kees Cook wrote:
> > On Thu, Feb 13, 2025 at 08:41:16PM +, Andrew Cooper wrote:
> > > On 13/02/2025 8:28 pm, Kees Cook wrote:
> > > > On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> >
On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
>
> > Right, the "if they can control a function pointer" is the part I'm
> > focusing on. This attack depends on making an indirect call with a
> > controlled pointer. Non-
On Sat, Feb 15, 2025 at 12:11:17AM +, Andrew Cooper wrote:
> On 15/02/2025 12:07 am, Jennifer Miller wrote:
> > On Fri, Feb 14, 2025 at 11:06:50PM +, Andrew Cooper wrote:
> >> On 13/02/2025 11:24 pm, Jennifer Miller wrote:
> >>> On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
On 15/02/2025 12:07 am, Jennifer Miller wrote:
> On Fri, Feb 14, 2025 at 11:06:50PM +, Andrew Cooper wrote:
>> On 13/02/2025 11:24 pm, Jennifer Miller wrote:
>>> On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
>>> Still, I hadn't considered misusing readonly/unmapped pages on the
On Fri, Feb 14, 2025 at 11:06:50PM +, Andrew Cooper wrote:
> On 13/02/2025 11:24 pm, Jennifer Miller wrote:
> > On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
> ; swap stacks as normal
> movQWORD PTR gs:[rip+0x7f005f85],rsp # 0x6014
>
> mo
On 13/02/2025 11:24 pm, Jennifer Miller wrote:
> On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
; swap stacks as normal
movQWORD PTR gs:[rip+0x7f005f85],rsp # 0x6014
movrsp,QWORD PTR gs:[rip+0x7f02c56d] # 0x2c618
>> ... these are memory a
On Thu, Feb 13, 2025 at 08:23:34PM +0100, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 7:15 AM Jennifer Miller 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 c
On Thu, Feb 13, 2025 at 08:41:16PM +, Andrew Cooper wrote:
> The problem is that SYSCALL entry/exit is a toxic operating mode,
> because you only have to think about sneezing and another user->kernel
> priv-esc appears.
For a very brief moment I thought we could leave out the ENDBR there and
On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> Right, the "if they can control a function pointer" is the part I'm
> focusing on. This attack depends on making an indirect call with a
> controlled pointer. Non-FineIBT CFI will protect against that step,
> so I think this is only an i
On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> But, FRED support is slated for PantherLake/DiamondRapids which haven't
> shipped yet, so are no use to the problem right now.
FRED also fixes this IBT 'oopsie' IIRC.
On Fri, Feb 14, 2025 at 12:24 AM Jennifer Miller wrote:
> On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
> > On 13/02/2025 7:23 pm, Jann Horn wrote:
> > > How would we actually do that overwriting and restoring of
> > > KERNEL_GS_BASE? Would we need a scratch register for that?
> >
On Thu, Feb 13, 2025 at 09:24:18PM +, Andrew Cooper wrote:
> On 13/02/2025 7:23 pm, Jann Horn wrote:
> > On Thu, Feb 13, 2025 at 7:15 AM Jennifer Miller wrote:
> >> Here is some napkin asm for this I wrote for the 64-bit syscall entrypoint,
> >> I think more or less the same could be done for
On 13/02/2025 7:23 pm, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 7:15 AM Jennifer Miller wrote:
>> Here is some napkin asm for this I wrote for the 64-bit syscall entrypoint,
>> I think more or less the same could be done for the other entrypoints.
>>
>> ```
>> endbr64
>> test rsp, rsp
>>
On Thu, Feb 13, 2025 at 9:53 PM Kees Cook wrote:
> On Thu, Feb 13, 2025 at 08:41:16PM +, Andrew Cooper wrote:
> > On 13/02/2025 8:28 pm, Kees Cook wrote:
> > > On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> > Assuming this is an issue you all feel is worth addressing, I
On Thu, Feb 13, 2025 at 08:41:16PM +, Andrew Cooper wrote:
> On 13/02/2025 8:28 pm, Kees Cook wrote:
> > On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> Assuming this is an issue you all feel is worth addressing, I will
> continue working on providing a patch. I'm con
On 13/02/2025 8:28 pm, Kees Cook wrote:
> On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
Assuming this is an issue you all feel is worth addressing, I will
continue working on providing a patch. I'm concerned though that the
overhead from adding a wrmsr on both syscal
On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> >> Assuming this is an issue you all feel is worth addressing, I will
> >> continue working on providing a patch. I'm concerned though that the
> >> overhead from adding a wrmsr on both syscall entry and exit to
> >> overwrite and res
On Thu, Feb 13, 2025 at 7:15 AM Jennifer Miller wrote:
> On Wed, Feb 12, 2025 at 11:29:02PM +0100, Jann Horn wrote:
> > +Andy Lutomirski (X86 entry code maintainer)
> >
> > On Wed, Feb 12, 2025 at 10:08 PM Jennifer Miller wrote:
> > > As part of a recently accepted paper we demonstrated that sysc
On Wed, Feb 12, 2025 at 11:29:02PM +0100, Jann Horn wrote:
> +Andy Lutomirski (X86 entry code maintainer)
>
> On Wed, Feb 12, 2025 at 10:08 PM Jennifer Miller wrote:
> > As part of a recently accepted paper we demonstrated that syscall
> > entrypoints can be misused on x86-64 systems to generical
On 13/02/2025 2:09 am, Jann Horn wrote:
> On Thu, Feb 13, 2025 at 2:31 AM Andrew Cooper
> wrote:
Assuming this is an issue you all feel is worth addressing, I will
continue working on providing a patch. I'm concerned though that the
overhead from adding a wrmsr on both syscall entr
On Thu, Feb 13, 2025 at 2:31 AM Andrew Cooper wrote:
> >> Assuming this is an issue you all feel is worth addressing, I will
> >> continue working on providing a patch. I'm concerned though that the
> >> overhead from adding a wrmsr on both syscall entry and exit to
> >> overwrite and restore the
>> Assuming this is an issue you all feel is worth addressing, I will
>> continue working on providing a patch. I'm concerned though that the
>> overhead from adding a wrmsr on both syscall entry and exit to
>> overwrite and restore the KERNEL_GS_BASE MSR may be quite high, so
>> any feedback in re
+Andy Lutomirski (X86 entry code maintainer)
On Wed, Feb 12, 2025 at 10:08 PM Jennifer Miller wrote:
> As part of a recently accepted paper we demonstrated that syscall
> entrypoints can be misused on x86-64 systems to generically bypass
> FineIBT/KERNEL_IBT from forwards-edge control flow hijack
41 matches
Mail list logo
