Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220713203409.559c5464@canb.auug.org.au> <Ys6u88DqQdgmkWWf@hirez.programming.kicks-ass.net>
 <CANiq72k_dtr2=KX-WheUiM2v2370imAdWFawJR+8P41L7HjwpA@mail.gmail.com> <YtEs9H+JEDUq6NNm@worktop.programming.kicks-ass.net>
In-Reply-To: <YtEs9H+JEDUq6NNm@worktop.programming.kicks-ass.net>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Fri, 15 Jul 2022 13:01:04 +0200
Message-ID: <CANiq72=oOEdxY1bEA3YFwFkSiYk+Uwv=x-4yEwHgCz0SizY66w@mail.gmail.com>
Subject: Re: linux-next: manual merge of the rust tree with Linus' tree
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Adam Bratschi-Kaye <ark.email@gmail.com>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Antonio Terceiro <antonio.terceiro@linaro.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Boris-Chengbiao Zhou <bobo1239@web.de>,
        Borislav Petkov <bp@suse.de>, Daniel Xu <dxu@dxuuu.xyz>,
        Dariusz Sosnowski <dsosnowski@dsosnowski.pl>,
        David Gow <davidgow@google.com>,
        Douglas Su <d0u9.su@outlook.com>, Finn Behrens <me@kloenk.de>,
        Gary Guo <gary@garyguo.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Miguel Cano <macanroj@gmail.com>,
        Miguel Ojeda <ojeda@kernel.org>,
        Sven Van Asbroeck <thesven73@gmail.com>,
        Wedson Almeida Filho <wedsonaf@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Sami Tolvanen <samitolvanen@google.com>,
        joao@overdrivepizza.com, Kees Cook <keescook@chromium.org>,
        Arthur Cohen <arthur.cohen@embecosm.com>,
        Antoni Boucher <bouanto@zoho.com>,
        Josh Triplett <josh@joshtriplett.org>,
        Philip Herron <philip.herron@embecosm.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Ok; I'm supposing that'll be sorted by the time rust happens.

No, it most likely won't, and I don't see why you would assume that,
or why we would want to block Rust support on that.

> There's quite a few things affecting code-gen; rustc not using the exact
> same compiler arguments is going to create a head-ache.

Yes, a GCC-like driver in `rustc` would be nice for projects like the
kernel. The GCC Rust project will support GCC-like flags, as far as I
understand.

(Cc'ing Antoni, Arthur, Josh, Philip).

> But does it support everything clang does now? If not, you need to
> express that in Kconfig and disable the features it doesn't carry. So
> even for a single rustc version will you need RUSTC_HAS_ stuff.

You could still make everything work around the `RUST` symbol, no need
to "litter everything" (as you said) just yet. :)

> What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
> doesn't seem to have anything there, suggesting I can't build an IBT
> enabled kernel if rust is on (or rather, it'll build, but it'll also
> burn at boot).
>
> What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
> doesn't have it? Same if LLVM finally stops generating those pesky
> conditional tail-calls, will rust continue emitting them?
>
> I'm thinking of the kCFI work, will rustc support that from day 1 or
> will that only work when not building any rust.
>
> There being a single rustc is not a single target, every compiler
> version grows (and breaks) new features. And for some reason we seem to
> change the actual kernel calling convetion a lot of late :/
>
> Currently we can support a feature when one compiler version supports it
> (either gcc or clang), but the moment rust becomes a mandatory part of
> the kernel build (and I dread that day) we'll need to
> wait/update/wrangle at least two different toolchains to implement the
> feature in a consistent manner before we can use it.
>
> I also don't see any RUST -mfentry support...

I think you are getting way too ahead.

Merging the Rust support now is meant to evaluate whether Rust _as a
language_ makes sense for the kernel, whether we can write enough % of
kernel code in the safe subset (and whether that brings enough
advantages), etc.

It is not meant to provide "day 1 support" for everything. In fact,
getting merged now is what will allow to grow support for everything
needed everywhere: not just in terms of compiler flags, faster
integration of LLVM codegen/mitigation features in `rustc`, new
frontends and backends (`rustc_codegen_gcc` and GCC Rust), etc.; but
also within the kernel, in terms of safe abstractions for kernel APIs,
kernel maintainers' experience with Rust, etc.

Cheers,
Miguel