linux-kernel - Re: linux-next: manual merge of the rust tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANiq72=oOEdxY1bEA3YFwFkSiYk+Uwv=x-4yEwHgCz0SizY66w@mail.gmail.com>
Date:   Fri, 15 Jul 2022 13:01:04 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Antonio Terceiro <antonio.terceiro@...aro.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Boris-Chengbiao Zhou <bobo1239@....de>,
        Borislav Petkov <bp@...e.de>, Daniel Xu <dxu@...uu.xyz>,
        Dariusz Sosnowski <dsosnowski@...snowski.pl>,
        David Gow <davidgow@...gle.com>,
        Douglas Su <d0u9.su@...look.com>, Finn Behrens <me@...enk.de>,
        Gary Guo <gary@...yguo.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Miguel Cano <macanroj@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        joao@...rdrivepizza.com, Kees Cook <keescook@...omium.org>,
        Arthur Cohen <arthur.cohen@...ecosm.com>,
        Antoni Boucher <bouanto@...o.com>,
        Josh Triplett <josh@...htriplett.org>,
        Philip Herron <philip.herron@...ecosm.com>
Subject: Re: linux-next: manual merge of the rust tree with Linus' tree

On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <peterz@...radead.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