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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YtEs9H+JEDUq6NNm@worktop.programming.kicks-ass.net>
Date:   Fri, 15 Jul 2022 11:01:40 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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>,
        samitolvanen@...gle.com, joao@...rdrivepizza.com,
        keescook@...omium.org
Subject: Re: linux-next: manual merge of the rust tree with Linus' tree

On Fri, Jul 15, 2022 at 03:13:17AM +0200, Miguel Ojeda wrote:
> On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Does Rust have the equivalent of -mfunction-return=thunk-extern ?
> 
> While GCC has had it for a while, Nick just landed 2 days ago the
> X86ReturnThunks pass in LLVM, so it will take some time to arrive in
> rustc.
> 
> I have naively backported it to rustc and hacked it so that I set the
> LLVM attribute for all functions, and I am getting the rets replaced
> in Rust functions, e.g.
> 
> (gdb) disassemble a::f
> Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
>    ...
>    0x0000000000008a1f <+31>: pop    %rbp
>    0x0000000000008a20 <+32>: jmp    0x8ce0 <__x86_return_thunk>
> 
> A trivial userspace program that counts the times that it goes through
> the return thunk also appears to work.

Ok; I'm supposing that'll be sorted by the time rust happens.

> > Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> > What if C has the relevant option but Rust does not; then we must not
> > have the feature enabled or there will be a mis-match.
> 
> I guess that would depend on the particular option: whether it applies
> to Rust at all, whether it creates an incompatibility or not, etc.

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

> > Do we now have to litter everythign with RUSTC_HAS_ ?
> 
> Why? Only a single `rustc` version is targeted at the moment, so it is
> possible to statically know what it supports.

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.

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...