Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate
From:   comex <comexk@gmail.com>
In-Reply-To: <YysdZIGp13ye0D4z@boqun-archlinux>
Date:   Sun, 2 Oct 2022 22:03:22 -0400
Cc:     Gary Guo <gary@garyguo.net>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Wedson Almeida Filho <wedsonaf@gmail.com>,
        Matthew Wilcox <willy@infradead.org>,
        Kees Cook <keescook@chromium.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
        Konstantin Shelekhin <k.shelekhin@yadro.com>, ojeda@kernel.org,
        ark.email@gmail.com, bjorn3_gh@protonmail.com, bobo1239@web.de,
        bonifaido@gmail.com, davidgow@google.com, dev@niklasmohrin.de,
        dsosnowski@dsosnowski.pl, foxhlchen@gmail.com,
        geofft@ldpreload.com, gregkh@linuxfoundation.org,
        jarkko@kernel.org, john.m.baublitz@gmail.com,
        leseulartichaut@gmail.com, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, me@kloenk.de, milan@mdaverde.com,
        mjmouse9999@gmail.com, patches@lists.linux.dev,
        rust-for-linux@vger.kernel.org, thesven73@gmail.com,
        viktor@v-gar.de, Andreas Hindborg <andreas.hindborg@wdc.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF630FE4-8DDB-43AE-A2B3-1708E260062A@gmail.com>
References: <YyivY6WIl/ahZQqy@wedsonaf-dev>
 <CAHk-=whm5Ujw-yroDPZWRsHK76XxZWF1E9806jNOicVTcQC6jw@mail.gmail.com>
 <Yyjut3MHooCwzHRc@wedsonaf-dev>
 <CAHk-=wityPWw4YkHeMNU4iGanyiC3UwDRhbOHYCJrhB2paCGwA@mail.gmail.com>
 <CAFRnB2VPpLSMqQwFPEjZhde8+-c6LLms54QkMt+wZPjOTULESw@mail.gmail.com>
 <CAHk-=wiyD6KqZN8jFkMHPRPxrbyJEUDRP6+WaH9Q9hjDB5i1zg@mail.gmail.com>
 <CAHk-=wj6sDFk8ZXSEKUMj-J9zfrMSSO3jhBEaveVaJSUpr=O=w@mail.gmail.com>
 <87a66uxcpc.fsf@email.froward.int.ebiederm.org>
 <20220920233947.0000345c@garyguo.net>
 <C85081E7-99CB-421F-AA3D-60326A5181EB@gmail.com>
 <YysdZIGp13ye0D4z@boqun-archlinux>
To:     Boqun Feng <boqun.feng@gmail.com>
Precedence: bulk


>> On the other hand, it ought to be feasible to implement that kind of
>> =E2=80=99negative reasoning' as a custom lint.  It might not work as =
well as
>> something built into the language, but it should work decently well,
>> and could serve as a prototype for a future built-in feature.
>=20
> Interesting, do you have an example somewhere?
>=20
> Regards,
> Boqun

After some searching, I found this, which someone wrote several years =
ago for a
very similar purpose:

https://github.com/thepowersgang/tag_safe/

> This is a linter designed originally for use with a kernel, where =
functions
> need to be marked as "IRQ safe" (meaning they are safe to call within =
an IRQ
> handler, and handle the case where they may interrupt themselves).

> If a function is annotated with #[req_safe(ident)] (where ident can be
> anything, and defines the type of safety) this linter will check that =
all
> functions called by that function are either annotated with the same
> annotation or #[is_safe(ident)], OR they do not call functions with =
the
> reverse #[is_unsafe(ident)] annotation.

Note that the code won't work as-is with recent rustc.  rustc's API for =
custom
lints is not stable, and in fact rustc has deprecated linter plugins =
entirely
[1], though there are alternative approaches to using custom lints [2].  =
Still,
it's a good example of the approach.

One fundamental caveat is that it doesn't seem to have the =
sophistication
needed to be sound with respect to indirect calls.

For example, suppose you have a function that fetches a callback from =
some
structure and calls it.  Whether this function is IRQ-safe depends on =
whether
the callback is expected to be IRQ-safe, so in order to safety-check =
this, you
would need an annotation on either the callback field or the function =
pointer
type.  This is more complex than just putting annotations on function
definitions.

Or suppose you have the following code:

    fn foo() {
        bar(|| do_something_not_irq_safe());
    }

If `foo` is expected to be IRQ-safe, this may or may not be sound, =
depending on
whether `bar` calls the callback immediately or saves it for later.  If =
`bar`
saves it for later, then it could be marked unconditionally IRQ-safe.  =
But if
`bar` calls it immediately, then it's neither IRQ-safe nor IRQ-unsafe, =
but
effectively generic over IRQ safety.  You could pessimistically mark it
IRQ-unsafe, but Rust has tons of basic helper methods that accept =
callbacks and
call them immediately; not being able to use any of them in an IRQ-safe =
context
would be quite limiting.

In short, a fully sound approach requires not just checking which =
functions
call which, but having some kind of integration with the type system.  =
This is
the kind of issue that I was thinking of when I said a custom lint may =
not work
as well as something built into the language.

However, I do think it's *possible* to handle it soundly from a lint,
especially if it focuses on typical use cases and relies on manual =
annotations
for the rest.  Alternately, even an unsound lint would be a good first =
step.
It wouldn't really comport with Rust's ethos of making safety guarantees
ironclad rather than heuristic, but it would serve as a good proof of =
concept
for a future language feature, while likely being helpful in practice in =
the
short term.

[1] https://github.com/rust-lang/rust/pull/64675/files
[2] =
https://www.trailofbits.com/post/write-rust-lints-without-forking-clippy