linux-hardening - Re: [PATCH v5 00/15] x86: Add support for Clang CFI

lists.openwall.net		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 linux-cve-announce 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:   Wed, 27 Oct 2021 16:36:45 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        X86 ML <x86@...nel.org>, Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-hardening@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        llvm@...ts.linux.dev
Subject: Re: [PATCH v5 00/15] x86: Add support for Clang CFI

On Wed, Oct 27, 2021 at 04:18:17PM +0200, Ard Biesheuvel wrote:
> On Wed, 27 Oct 2021 at 16:03, Peter Zijlstra <peterz@...radead.org> wrote:

> > /*
> >  * Turns a Clang CFI jump-table entry into an actual function pointer.
> >  * These jump-table entries are simply jmp.d32 instruction with their
> >  * relative offset pointing to the actual function, therefore decode the
> >  * instruction to find the real function.
> >  */
> > static __always_inline void *nocfi_ptr(void *func)
> > {
> >         union text_poke_insn insn = *(union text_poke_insn *)func;

also, probably, for the paranoid amongst us:

	if (WARN_ON_ONCE(insn.opcode != JMP32_INSN_OPCODE))
		return func;

> >         return func + sizeof(insn) + insn.disp;
> > }
> >
> > But really, that wants to be a compiler intrinsic.
> 
> Agreed. We could easily do something similar on arm64, but I'd prefer
> to avoid that too.

Right, because on x86 CET-IBT will force that entry to have a different
form (and size), similar on arm64 with BTI.

I was thinking the compiler really should implicitly do this conversion
when a function pointer is cast to an integer type. But barring that, we
really need an intrinsic to perform this.

Also, perhaps the compiler should admit it's doing dodgy crap and
introduce the notion of address spaces and use the type system to
separate these two forms.