Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 14 Oct 2021 09:07:57 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Sami Tolvanen <samitolvanen@google.com>, x86@kernel.org,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Sedat Dilek <sedat.dilek@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
        llvm@lists.linux.dev
Subject: Re: [PATCH v5 09/15] x86: Use an opaque type for functions not
 callable from C
Message-ID: <202110140904.41B5183E@keescook>
References: <20211013181658.1020262-1-samitolvanen@google.com>
 <20211013181658.1020262-10-samitolvanen@google.com>
 <YWgSwmzPFrRbMC1P@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YWgSwmzPFrRbMC1P@zn.tnic>
Precedence: bulk

On Thu, Oct 14, 2021 at 01:21:38PM +0200, Borislav Petkov wrote:
> 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@amacapital.net>
> > Suggested-by: Alexander Lobakin <alobakin@pm.me>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Tested-by: Sedat Dilek <sedat.dilek@gmail.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?

I don't think it's a super common thing to add, so in this case, yes,
I think doing it on a case-by-case basis will be fine. This is common
practice in the kernel; not everyone tests all CONFIGs, so stuff gets
missed, patches are sent, life goes on. :)

> 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[];

I'd _much_ prefer keeping the macro, as it explains what's going on,
which doesn't require a comment at every "extern const u8 foo[]" usage.
It serves as an annotation, etc.

And, there's been a lot of discussion on the best way to do this, what
to name it, etc. This looks to be the best option currently.

-Kees

-- 
Kees Cook