From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v4 05/17] ctype: Work around Clang -mbranch-protection=none bug Date: Mon, 29 Jun 2020 07:43:36 -0700 Message-ID: <202006290742.92EC7235@keescook> References: <20200629061840.4065483-1-keescook@chromium.org> <20200629061840.4065483-6-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Ard Biesheuvel Cc: Will Deacon , Dave Martin , clang-built-linux , Catalin Marinas , Mark Rutland , Peter Collingbourne , James Morse , Borislav Petkov , Thomas Gleixner , Ingo Molnar , Russell King , Masahiro Yamada , Arvind Sankar , Nick Desaulniers , Nathan Chancellor , Arnd Bergmann , X86 ML , linux-arch , linux-efi , Linux ARM List-Id: linux-arch.vger.kernel.org On Mon, Jun 29, 2020 at 10:15:47AM +0200, Ard Biesheuvel wrote: > On Mon, 29 Jun 2020 at 08:18, Kees Cook wrote: > > > > In preparation for building efi/libstub with -mbranch-protection=none > > (EFI does not support branch protection features[1]), add no-op code > > to work around a Clang bug that emits an unwanted .note.gnu.property > > section for object files without code[2]. > > > > [1] https://lore.kernel.org/lkml/CAMj1kXHck12juGi=E=P4hWP_8vQhQ+-x3vBMc3TGeRWdQ-XkxQ@mail.gmail.com > > [2] https://bugs.llvm.org/show_bug.cgi?id=46480 > > > > Cc: Ard Biesheuvel > > Cc: Will Deacon > > Cc: Dave Martin > > Cc: clang-built-linux@googlegroups.com > > Signed-off-by: Kees Cook > > --- > > lib/ctype.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/lib/ctype.c b/lib/ctype.c > > index c819fe269eb2..21245ed57d90 100644 > > --- a/lib/ctype.c > > +++ b/lib/ctype.c > > @@ -36,3 +36,13 @@ _L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L, /* 224-239 */ > > _L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L}; /* 240-255 */ > > > > EXPORT_SYMBOL(_ctype); > > + > > +/* > > + * Clang will generate .note.gnu.property sections for object files > > + * without code, even in the presence of -mbranch-protection=none. > > + * To work around this, define an unused static function. > > + * https://bugs.llvm.org/show_bug.cgi?id=46480 > > + */ > > +#ifdef CONFIG_CC_IS_CLANG > > +void __maybe_unused __clang_needs_code_here(void) { } > > +#endif > > -- > > 2.25.1 > > > > I take it we don't need this horrible hack if we build the EFI stub > with branch protections and filter out the .note.gnu.property section > explicitly? Correct. > Sorry to backpedal, but that is probably a better approach after all, > given that the instructions don't hurt, and we will hopefully be able > to arm them once UEFI (as well as PE/COFF) gets around to describing > this in a way that both the firmware and the OS can consume. Okay, will revert to the v3 solution. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733224AbgF2Tcn (ORCPT ); Mon, 29 Jun 2020 15:32:43 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEEB9C02F004 for ; Mon, 29 Jun 2020 07:43:38 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id q90so7352159pjh.3 for ; Mon, 29 Jun 2020 07:43:38 -0700 (PDT) Date: Mon, 29 Jun 2020 07:43:36 -0700 From: Kees Cook Subject: Re: [PATCH v4 05/17] ctype: Work around Clang -mbranch-protection=none bug Message-ID: <202006290742.92EC7235@keescook> References: <20200629061840.4065483-1-keescook@chromium.org> <20200629061840.4065483-6-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Ard Biesheuvel Cc: Will Deacon , Dave Martin , clang-built-linux , Catalin Marinas , Mark Rutland , Peter Collingbourne , James Morse , Borislav Petkov , Thomas Gleixner , Ingo Molnar , Russell King , Masahiro Yamada , Arvind Sankar , Nick Desaulniers , Nathan Chancellor , Arnd Bergmann , X86 ML , linux-arch , linux-efi , Linux ARM , Linux Kernel Mailing List Message-ID: <20200629144336.dsgp3PiuwiFg4ykwOYYK9VdiBDgvkEcqgwHtJixfP_M@z> On Mon, Jun 29, 2020 at 10:15:47AM +0200, Ard Biesheuvel wrote: > On Mon, 29 Jun 2020 at 08:18, Kees Cook wrote: > > > > In preparation for building efi/libstub with -mbranch-protection=none > > (EFI does not support branch protection features[1]), add no-op code > > to work around a Clang bug that emits an unwanted .note.gnu.property > > section for object files without code[2]. > > > > [1] https://lore.kernel.org/lkml/CAMj1kXHck12juGi=E=P4hWP_8vQhQ+-x3vBMc3TGeRWdQ-XkxQ@mail.gmail.com > > [2] https://bugs.llvm.org/show_bug.cgi?id=46480 > > > > Cc: Ard Biesheuvel > > Cc: Will Deacon > > Cc: Dave Martin > > Cc: clang-built-linux@googlegroups.com > > Signed-off-by: Kees Cook > > --- > > lib/ctype.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/lib/ctype.c b/lib/ctype.c > > index c819fe269eb2..21245ed57d90 100644 > > --- a/lib/ctype.c > > +++ b/lib/ctype.c > > @@ -36,3 +36,13 @@ _L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L, /* 224-239 */ > > _L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L}; /* 240-255 */ > > > > EXPORT_SYMBOL(_ctype); > > + > > +/* > > + * Clang will generate .note.gnu.property sections for object files > > + * without code, even in the presence of -mbranch-protection=none. > > + * To work around this, define an unused static function. > > + * https://bugs.llvm.org/show_bug.cgi?id=46480 > > + */ > > +#ifdef CONFIG_CC_IS_CLANG > > +void __maybe_unused __clang_needs_code_here(void) { } > > +#endif > > -- > > 2.25.1 > > > > I take it we don't need this horrible hack if we build the EFI stub > with branch protections and filter out the .note.gnu.property section > explicitly? Correct. > Sorry to backpedal, but that is probably a better approach after all, > given that the instructions don't hurt, and we will hopefully be able > to arm them once UEFI (as well as PE/COFF) gets around to describing > this in a way that both the firmware and the OS can consume. Okay, will revert to the v3 solution. -- Kees Cook