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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 2 Nov 2021 22:48:19 +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 Tue, Nov 02, 2021 at 07:18:53PM +0100, Ard Biesheuvel wrote:

> > The range check isn't fundamental to CFI, having a check is the
> > important thing AFAIU.
> Agreed. If the call site has a direct branch, it doesn't need the range check.

That, from the earlier email:

 | And have the actual indirect callsite look like:
 |        # r11 - &foo
 |        ALTERNATIVE_2   "cs call __x86_indirect_thunk_r11",
 |                        "cs call __x86_indirect_cfi_deadbeef", X86_FEATURE_CFI
 |                        "cs call __x86_indirect_ibt_deadbeef", X86_FEATURE_IBT

So the callsite has a direct call to the hash-specific and cfi-type
specific thunk, which then does an (indirect) tail-call.

The CFI one does the hash check in the thunk and jumps to the function
proper, the IBT one on does it in the landing-pad.

The !CFI one ignore it all and simply does an indirect call (retpoline
aided or otherwise) to the function proper -- in which case we can free
all the thunks.

Powered by blists - more mailing lists