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:   Wed, 3 Nov 2021 10:01:40 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Peter Zijlstra' <>,
        Andy Lutomirski <>
CC:     Kees Cook <>,
        Ard Biesheuvel <>,
        "Sami Tolvanen" <>,
        Mark Rutland <>,
        the arch/x86 maintainers <>,
        Josh Poimboeuf <>,
        Nathan Chancellor <>,
        "Nick Desaulniers" <>,
        Sedat Dilek <>,
        Steven Rostedt <>,
        "" <>,
        Linux Kernel Mailing List <>,
        "" <>
Subject: RE: [PATCH] static_call,x86: Robustify trampoline patching

From: Peter Zijlstra
> Sent: 03 November 2021 08:36
> On Tue, Nov 02, 2021 at 05:20:05PM -0700, Andy Lutomirski wrote:
> > I think that's a big mistake -- any sane ENDBR-using scheme would
> > really prefer that ENDBR to be right next to the actual function body,
> > and really any scheme would benefit due to better cache locality.
> Agreed, IBT/BTI want the landing pad in front of the actual function.
> > But, more importantly, IMO any sane ENDBR-using scheme wants to
> > generate the indirect stub as part of code gen for the actual
> > function.
> Sorta, I really want to be able to not have a landing pad for functions
> whose address is never taken. At that point it doesn't matter if it gets
> generated along with the function and then stripped/poisoned later, or
> generated later.
> As such, the landing pad should not be part of the function proper,
> direct calls should never observe it.
> Less landing pads is more better.

One problem is when a direct call is 'too far' for a call instruction.
IIRC this can happen in arm64 with modules (all 64bit except x86?).
So an indirect call has to be used instead - which needs the landing pad.
Although it may actually be better to put a trampoline (landing pad
+ near jump) elsewhere and have the module loader do the correct fixup.
(Is the loader already generating a trampoline in the module code?)
The function body can then be cache-line aligned - with its benefits.

Can't anything that can write instructions always use a retpoline
to implement a jump indirect to an arbitrary address?
(Not to mention just generating the required code rather than a call.)

AFAICT CFI is all about detecting invalid values in function pointer tables.
It doesn't really protect in any way from JIT code doing incorrect things.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists