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:   Thu, 25 Mar 2021 16:27:51 -0700
From:   Sami Tolvanen <>
To:     Mark Rutland <>,
        Peter Collingbourne <>
Cc:     Kees Cook <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Masahiro Yamada <>,
        Will Deacon <>, Jessica Yu <>,
        Arnd Bergmann <>, Tejun Heo <>,
        "Paul E. McKenney" <>,
        Christoph Hellwig <>,
        Peter Zijlstra <>,
        bpf <>,,
        linux-arch <>,
        linux-arm-kernel <>,
        linux-kbuild <>,
        PCI <>,
        LKML <>
Subject: Re: [PATCH v3 12/17] arm64: implement __va_function

On Thu, Mar 25, 2021 at 3:38 AM Mark Rutland <> wrote:
> On Tue, Mar 23, 2021 at 01:39:41PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> > instrumented C code with jump table addresses. This change implements
> > the __va_function() macro, which returns the actual function address
> > instead.
> >
> > Signed-off-by: Sami Tolvanen <>
> > Reviewed-by: Kees Cook <>
> Is there really no attribute or builtin that can be used to do this
> without assembly?

I don't think the compiler currently offers anything that could help
us here. Peter, can you think of another way to avoid the function
address to jump table address conversion with

> IIUC from other patches the symbol tables will contain the "real"
> non-cfi entry points (unless we explciitly asked to make the jump table
> address canonical), so AFAICT here the compiler should have all the
> necessary information to generate either the CFI or non-CFI entry point
> addresses, even if it doesn't expose an interface for that today.
> It'd be a lot nicer if we could get the compiler to do this for us.

I agree, that would be quite useful in the kernel.


Powered by blists - more mailing lists