linux-kernel - Re: [PATCH 00/13] [RFC] Rust support

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]

Date:   Thu, 22 Apr 2021 23:28:57 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Wedson Almeida Filho <wedsonaf@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/13] [RFC] Rust support

Hi Linus,

Thanks for all those very good questions (and thanks for the positive
tone!). I will try to complement Wedson's answer in a couple places.

On Thu, Apr 22, 2021 at 12:03 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> But as subsystem maintainer I'd like a clear picture of this wrapper
> overhead, what does it usually entail? A typical kernel API has
> vtable and a few variables, not much more than that.

If you mean runtime-overhead, i.e. performance, it should be very
small or even zero. It should be possible to perform LTO across
languages too.

If you mean source code overhead, or cognitive overhead, then it is
quite a bit, yes. Please see below.

> It becomes obvious that as subsystem maintainer for the Linux kernel
> a casual drive-by experience with Rust is not going to suffice by far.
>
> All subsystem maintainers are expected to understand and maintain
> wrappers like these, right? That means all subsystem maintainers need
> to be elevated to understand the above without effort if you wake them
> up in their sleep at 4 in the morning.

I would say so, at least if longer-term a substantial amount of new
drivers are written in Rust. That is why I mentioned this as the very
first thing in the RFC. Rust does require some learning to use, even
by C experts.

Having said that, someone that is already a kernel developer and/or a
C expert is in a very good position to learn how Rust approaches
things and the main "new" concepts it introduces.

In the end, Rust is addressing some of the familiar problems that we
face when programming in C and C++.

> Get me right, we are of course good at doing really complicated stuff,
> that's what engineers do. But we are not Iron Man. We need a clear
> way into understanding and maintaining wrappers and we need support
> with it when we don't understand it, so the kernel would need a Rust
> wrapper maintainer that we can trust to stay around for the long term,
> i.e. until their retirement, while actively teaching others for decades.
> For an example see how RCU is maintained.

I hear you! I do not think it will take decades for kernel developers
to get up to speed, but I agree that having some help/backup is a very
good idea in the beginning.

Our hope is that, if Rust advantages prove themselves, then it will
the subsystem maintainers the ones that will want to create and
maintain the wrappers so that drivers in their tree are easier to
maintain and less prone to mistakes ;-)

Cheers,
Miguel