linux-kernel - Re: [PATCH v9 12/27] rust: add `kernel` crate

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: <87a66uxcpc.fsf@email.froward.int.ebiederm.org>
Date:   Tue, 20 Sep 2022 10:55:27 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Konstantin Shelekhin <k.shelekhin@...ro.com>, ojeda@...nel.org,
        ark.email@...il.com, bjorn3_gh@...tonmail.com, bobo1239@....de,
        bonifaido@...il.com, boqun.feng@...il.com, davidgow@...gle.com,
        dev@...lasmohrin.de, dsosnowski@...snowski.pl, foxhlchen@...il.com,
        gary@...yguo.net, geofft@...reload.com, gregkh@...uxfoundation.org,
        jarkko@...nel.org, john.m.baublitz@...il.com,
        leseulartichaut@...il.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, me@...enk.de, milan@...verde.com,
        mjmouse9999@...il.com, patches@...ts.linux.dev,
        rust-for-linux@...r.kernel.org, thesven73@...il.com,
        viktor@...ar.de, Andreas Hindborg <andreas.hindborg@....com>
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Mon, Sep 19, 2022 at 4:58 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> This is not some kind of "a few special things".
>>
>> This is things like absolutely _anything_ that allocates memory, or
>> takes a lock, or does a number of other things.
>
> Examples of "number of other things" ends up being things like
> "accessing user memory", which depending on what you are doing may be
> very common too.
>
> And btw, it's not only about the (multiple kinds of) atomic regions.
>
> We have other context rules in the kernel too, like "does floating
> point or vector unit calculations". Which you can actually do, but
> only in a kernel_fpu_begin/kernel_fpu_end region.
>
> Now, the floating point thing is rare enough that it's probably fine
> to just say "no floating point at all in Rust code".  It tends to be
> very special code, so you'd write it in C or inline assembly, because
> you're doing special things like using the vector unit for crypto
> hashes using special CPU instructions.

I just want to point out that there are ways of representing things like
the context you are running in during compile time.  I won't argue they
are necessarily practical, but there are ways and by exploring those
ways some practical solutions may result.

Instead of saying:
spin_lock(&lock);
do_something();
spin_unlock(&lock);

It is possible to say:
with_spin_lock(&lock, do_something());

This can be taken a step farther and with_spin_lock can pass a ``token''
say a structure with no members that disappears at compile time that
let's the code know it has the spinlock held.

In C I would do:
struct have_spin_lock_x {
	// nothing
};

do_something(struct have_spin_lock_x context_guarantee)
{
	...;
}

I think most of the special contexts in the kernel can be represented in
a similar manner.  A special parameter that can be passed and will
compile out.

I don't recall seeing anything like that tried in the kernel so I don't
know if it makes sense or if it would get too wordy to live, but it is
possible.  If passing a free context parameter is not too wordy it would
catch silly errors, and would hopefully leave more mental space for
developers to pay attention to the other details of the problems they
are solving.

*Shrug*  I don't know if rust allows for free parameters like that and
if it does I don't know if it would be cheap enough to live.

Eric