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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 1 Nov 2021 10:01:55 +0100
From:   Peter Zijlstra <>
To:     Ard Biesheuvel <>
Cc:     Sami Tolvanen <>,
        Mark Rutland <>, X86 ML <>,
        Kees Cook <>,
        Josh Poimboeuf <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Sedat Dilek <>,
        Steven Rostedt <>,,
        Linux Kernel Mailing List <>,
Subject: Re: [PATCH] static_call,x86: Robustify trampoline patching

On Mon, Nov 01, 2021 at 12:36:18AM +0100, Ard Biesheuvel wrote:
> On Sun, 31 Oct 2021 at 21:45, Peter Zijlstra <> wrote:
> >
> > On Sun, Oct 31, 2021 at 09:21:56PM +0100, Ard Biesheuvel wrote:
> >
> > > That means we can support static calls on arm64 now without breaking
> > > Clang CFI, and work on a solution for the redundant jumps on a more
> > > relaxed schedule.
> >
> > Yes, arm64 has a 'problem' with having already merged the clang-cfi
> > stuff :/
> >
> > I'm hoping the x86 solution can be an alternative CFI scheme, I'm
> > starting to really hate this one. And I'm not at all convinced the
> > proposed scheme is the best possible scheme given the constraints of
> > kernel code. AFAICT it's a compromise made in userspace.
> Your scheme only works with IBT: the value of %r11 is under the
> adversary's control so it could just point it at 'foo+0x10' if it
> wants to call foo indirectly, and circumvent the check. So without IBT
> (or BTI), I think the check fundamentally belongs in the caller, not
> in the callee.

How is that not true for the jump table approach? Like I showed earlier,
it is *trivial* to reconstruct the actual function pointer from a
jump-table entry pointer.

In any case, I really want the discussion to start at square one, and
show/explain why any chosen CFI scheme is actually good for the kernel.
Just because clang happened to have implemented it, doesn't make it the
most suitable scheme for the kernel.

Powered by blists - more mailing lists