linux-kernel - Re: [PATCH 0/6] Initial Rust V4L2 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]

Message-ID: <CANiq72kceQ8aWk7mtB4MoepUr3hNzF34d=DfVzdeCLGRAZwE6g@mail.gmail.com>
Date:   Wed, 12 Apr 2023 00:14:03 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Willy Tarreau <w@....eu>
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Daniel Almeida <daniel.almeida@...labora.com>,
        wedsonaf@...il.com, ojeda@...nel.org, mchehab@...nel.org,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

On Tue, Apr 11, 2023 at 10:26 PM Willy Tarreau <w@....eu> wrote:
>
> I don't know, maybe that would be a bit too fine. But at least a tainted
> flag is much less intrusive than forcing a user to rebuild and disable
> possibly important features that they would only be willing to disable
> for just a test.

It may be useful early on to have an easy way to check if any Rust
modules got loaded (though note that `RUST` is not tristate so far, so
you would still have something loaded). It could be extra optional
output in e.g. `lsmod`.

However, I don't know why that should imply tainting, especially
medium- and long-term -- please see below.

> have a hard time understanding that code that interacts with their
> subsystems, even if they try hard. It's exactly the same reason why
> 25 years ago Linus asked to stop abusing assembly code. If a language
> is only understood by a subset of developers, by nature it becomes
> more difficult to maintain in some areas.

Yeah, but that is why the idea was that Rust goes first into
subsystems where maintainers are willing to put some time into it now
and evaluate its merits. That way we also build more Rust expertise
across the kernel over time, so that later it is easier for others
(e.g. by having examples of API design and drivers, more people to
refer to, better tooling...).

But, yes, if Rust grows to be really successful within the kernel,
then at some point some basic understanding of Rust will be needed by
most kernel developers. I think that is fine, as long as there is
enough time to adjust.

> Sure, but as you said, "if they can". I thought that it could be both
> elegant, lightweight and convenient. But I'm not trying to sell this
> idea, just sharing it.

To be clear, it is still up to each subsystem to decide whether to
take Rust code. What I meant by "if they can" is that, if they are
willing to, then ideally the code would go through their tree too. The
exception are core APIs, where I asked for flexibility from all sides,
so that those subsystems willing to try Rust do not get completely
blocked.

Cheers,
Miguel