linux-hardening - Re: [PATCH v5 09/15] x86: Use an opaque type for functions not callable from C

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]

Message-ID: <YWgSwmzPFrRbMC1P@zn.tnic>
Date:   Thu, 14 Oct 2021 13:21:38 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Sami Tolvanen <samitolvanen@...gle.com>
Cc:     x86@...nel.org, Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        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@...r.kernel.org,
        llvm@...ts.linux.dev
Subject: Re: [PATCH v5 09/15] x86: Use an opaque type for functions not
 callable from C

On Wed, Oct 13, 2021 at 11:16:52AM -0700, Sami Tolvanen wrote:
> The kernel has several assembly functions that are not directly callable
> from C. Use an opaque type for these function prototypes to make misuse
> harder, and to avoid the need to annotate references to these functions
> for Clang's Control-Flow Integrity (CFI).
> 
> Suggested-by: Andy Lutomirski <luto@...capital.net>
> Suggested-by: Alexander Lobakin <alobakin@...me>
> Signed-off-by: Sami Tolvanen <samitolvanen@...gle.com>
> Reviewed-by: Kees Cook <keescook@...omium.org>
> Tested-by: Nick Desaulniers <ndesaulniers@...gle.com>
> Tested-by: Sedat Dilek <sedat.dilek@...il.com>
> ---
>  arch/x86/include/asm/ftrace.h         |  2 +-
>  arch/x86/include/asm/idtentry.h       | 10 +++++-----
>  arch/x86/include/asm/page_64.h        |  7 ++++---
>  arch/x86/include/asm/paravirt_types.h |  3 ++-
>  arch/x86/include/asm/processor.h      |  2 +-
>  arch/x86/include/asm/proto.h          | 25 +++++++++++++------------
>  arch/x86/include/asm/uaccess_64.h     |  9 +++------
>  arch/x86/kernel/alternative.c         |  2 +-
>  arch/x86/kernel/ftrace.c              |  2 +-
>  arch/x86/kernel/paravirt.c            |  4 ++--
>  arch/x86/kvm/emulate.c                |  4 ++--
>  arch/x86/kvm/kvm_emulate.h            |  9 ++-------
>  arch/x86/xen/enlighten_pv.c           |  6 +++---
>  arch/x86/xen/xen-ops.h                | 10 +++++-----
>  14 files changed, 45 insertions(+), 50 deletions(-)

No matter from which direction I look at it, wrapping some functions
which a crazy macro doesn't look good.

So what's the plan here?

Everytime someone adds an asm function which is not callable from C but
forgets to use that magic macro, someone from team CFI will send a patch
fixing that?

I.e., a whack-a-mole game?

If we're going to do that keep-CFI-working game, we might just as well
not do the macro but use the C code it evaluates to, so that at least it
looks ok-ish:

DECLARE_NOT_CALLED_FROM_C(int3_magic);

vs

extern const u8 int3_magic[];

(Just picked one at random).

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette