mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Andrea Righi <andrea.righi@canonical.com>
Cc: Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Wedson Almeida Filho <wedsonaf@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com, Kees Cook <keescook@chromium.org>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: allow to use INIT_STACK_ALL_ZERO
Date: Sat, 11 Feb 2023 05:44:33 -0800	[thread overview]
Message-ID: <4E6FDE1C-47B6-46A6-AF31-28AEB2348344@kernel.org> (raw)
In-Reply-To: <Y+daEOZgaiF3IMTX@righiandr-XPS-13-7390>

On February 11, 2023 1:04:16 AM PST, Andrea Righi <andrea.righi@canonical.com> wrote:
>On Fri, Feb 10, 2023 at 02:43:56PM -0800, Kees Cook wrote:
>> On February 10, 2023 1:51:41 PM PST, Andrea Righi <andrea.righi@canonical.com> wrote:
>> >With CONFIG_INIT_STACK_ALL_ZERO enabled, bindgen passes
>> >-ftrivial-auto-var-init=zero to clang, that triggers the following
>> >error:
>> >
>> > error: '-ftrivial-auto-var-init=zero' hasn't been enabled; enable it at your own peril for benchmarking purpose only with '-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang'
>> >
>> >However, this additional option that is currently required by clang is
>> >going to be removed in the future (as the name of the option suggests),
>> >likely with clang-17.
>> >
>> >So, make sure bindgen is using this extra option if the major version of
>> >the libclang used by bindgen is < 17.
>> >
>> >In this way we can enable CONFIG_INIT_STACK_ALL_ZERO with CONFIG_RUST
>> >without triggering any build error.
>> >
>> >Link: https://github.com/llvm/llvm-project/issues/44842
>> >Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
>> >---
>> >
>> >Changes in v2:
>> > - check the version of libclang used by bindgen to determine if we need
>> >   to pass the additional clang option
>> >
>> > rust/Makefile | 13 +++++++++++++
>> > 1 file changed, 13 insertions(+)
>> >
>> >diff --git a/rust/Makefile b/rust/Makefile
>> >index ff70c4c916f8..c77d7ce96a85 100644
>> >--- a/rust/Makefile
>> >+++ b/rust/Makefile
>> >@@ -269,6 +269,19 @@ BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
>> > # some configurations, with new GCC versions, etc.
>> > bindgen_extra_c_flags = -w --target=$(BINDGEN_TARGET)
>> > 
>> >+# Auto variable zero-initialization requires an additional special option with
>> >+# clang that is going to be removed sometimes in the future (likely in
>> >+# clang-17), so make sure to pass this option only if clang supports it
>> >+# (libclang major version < 17).
>> >+#
>> >+# https://github.com/llvm/llvm-project/issues/44842
>> >+ifdef CONFIG_INIT_STACK_ALL_ZERO
>> >+libclang_maj_ver=$(shell $(BINDGEN) $(srctree)/scripts/rust_is_available_bindgen_libclang.h 2>&1 | sed -ne 's/.*clang version \([0-9]*\).*/\1/p')
>> >+ifeq ($(shell expr $(libclang_maj_ver) \< 17), 1)
>> >+bindgen_extra_c_flags += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
>> >+endif
>> >+endif
>> 
>> This logic already exists in the top-level Makefile. How does -ftrivial-auto-var-init=zero make it into bindgen_c_flags normally? (I.e. why does the legacy -enable... option not?)
>
>If we're using gcc, the top-level Makefile doesn't set the clang
>options, so in this case CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER is
>undefined.  But then bindgen always relies on libclang to parse C, even
>if gcc is used globally, therefore it needs the extra clang flag.

Ah yes! Thank you, I keep forgetting about mixed compiler builds.

>
>Ideally it'd be nice if bindgen would support a gcc backend, but until
>then we need to do something special here, like this kind of duplicated
>logic...

Right. Yeah, good fix. One nit: the -enable... flag is removed in Clang 16+:

https://github.com/llvm/llvm-project/blob/llvmorg-16.0.0-rc2/clang/docs/ReleaseNotes.rst#deprecated-compiler-flags

With that fixed:

Reviewed-by: Kees Cook <keescook@chromium.org>


-- 
Kees Cook

  reply	other threads:[~2023-02-11 13:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 21:51 Andrea Righi
2023-02-10 22:43 ` Kees Cook
2023-02-11  9:04   ` Andrea Righi
2023-02-11 13:44     ` Kees Cook [this message]
2023-02-11 14:35       ` Andrea Righi
2023-04-06 22:52         ` Miguel Ojeda
2023-04-07  6:02           ` Andrea Righi
2023-04-09 20:49             ` Miguel Ojeda
2023-04-11  7:11               ` Andrea Righi
2023-04-11 11:17                 ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E6FDE1C-47B6-46A6-AF31-28AEB2348344@kernel.org \
    --to=kees@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=andrea.righi@canonical.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®