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: <CANiq72n=s23naD4-UkmuLesekDTf4b5bsmWc+fYANYPq+X1R9w@mail.gmail.com>
Date:   Tue, 11 Apr 2023 21:27:35 +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 6:52 PM Willy Tarreau <w@....eu> wrote:
>
> But if that code is only under a module, there's no need to turn all
> that code off if it's sufficient to be certain the module was no loaded.
> Plus it's more friendly to the user who doesn't have to rebuild a kernel,
> just blacklist a module and check that the kernel doesn't get tainted
> again.

That could apply to any foreign-to-us subsystems, including C code
too. Should we taint per subsystem so that we can easily check for
those that we may not trust?

I see one could argue for an experimental taint or making it depend on
something like `STAGING`, i.e. based on grounds of being new code. But
I don't see why that should be grounded on just being a different
language or not being able to read the code.

> It could depend on the layer where it plugs and the level of intimacy
> with the core. Sometimes you need a deep understanding of all interactions
> between elements to imagine possible scenarios.

Please note that the policy for submitting new Rust code is that the
respective kernel maintainers and their lists are contacted. We also
request that maintainers take the code through their tree if they can,
rather than going through the Rust tree, precisely so that maintainers
are aware of these potential interactions. See
https://rust-for-linux.com/contributing#the-rust-subsystem for
details.

Cheers,
Miguel