Messages in this thread | | | Date | Thu, 14 Oct 2021 09:07:57 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v5 09/15] x86: Use an opaque type for functions not callable from C |
| |
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
| |