Taint Analysis for Kernel Rust

Taint Analysis for Kernel Rust

[Xavier Denis]

Hi all,

I saw a tweet (https://twitter.com/marcan42/status/1526107814477074432) from Marcan about the need for some sort of taint / capability analysis in Rust4Linux, and was offering my services. 

If someone knows what kinds of analysis are needed and could let me know that would be great: is this intra-procedural? Inter-procedural? Are we dealing with simple binary taints? Or do we need arbitrary partial orders? How complete/precise do we need the procedure to be? 

Given an answer to these questions I think I can whip up a `cargo taint` command rather quickly, so let me know if this is useful or desired. 

PS: I gleaned from other threads that there’s a Zulip as well, would it be possible to get an invite? 

Best,

Xavier 

Re: Taint Analysis for Kernel Rust

[Miguel Ojeda]

Hi Xavier,

On Mon, May 16, 2022 at 9:39 PM Xavier Denis <xldenis@lri.fr> wrote:
>
> I saw a tweet (https://twitter.com/marcan42/status/1526107814477074432) from Marcan about the need for some sort of taint / capability analysis in Rust4Linux, and was offering my services.
>
> If someone knows what kinds of analysis are needed and could let me know that would be great: is this intra-procedural? Inter-procedural? Are we dealing with simple binary taints? Or do we need arbitrary partial orders? How complete/precise do we need the procedure to be?

There have been discussions in the past about annotating functions in
similar ways ("function context restrictions", "colored unsafe",
etc.), and we recently brought it up in November's Rust CTCFT too.
However, how the feature could work is to be discussed and nobody has
yet put time on it (as far as I am aware).

> Given an answer to these questions I think I can whip up a `cargo taint` command rather quickly, so let me know if this is useful or desired.

Note that the kernel does not use Cargo at the moment.

> PS: I gleaned from other threads that there’s a Zulip as well, would it be possible to get an invite?

Of course, invitation sent -- welcome!

Cheers,
Miguel

Re: Taint Analysis for Kernel Rust

[Xavier Denis]

> Le 16 mai 2022 à 23:17, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> a écrit :
> 
> Hi Xavier,
> 
>> On Mon, May 16, 2022 at 9:39 PM Xavier Denis <xldenis@lri.fr> wrote:
>> 
>> I saw a tweet (https://twitter.com/marcan42/status/1526107814477074432) from Marcan about the need for some sort of taint / capability analysis in Rust4Linux, and was offering my services.
>> 
>> If someone knows what kinds of analysis are needed and could let me know that would be great: is this intra-procedural? Inter-procedural? Are we dealing with simple binary taints? Or do we need arbitrary partial orders? How complete/precise do we need the procedure to be?
> 
> There have been discussions in the past about annotating functions in
> similar ways ("function context restrictions", "colored unsafe",
> etc.), and we recently brought it up in November's Rust CTCFT too.
> However, how the feature could work is to be discussed and nobody has
> yet put time on it (as far as I am aware).
Is there any interest in a prototype? Doesn’t the kernel already use a similar system for C?
> 
>> Given an answer to these questions I think I can whip up a `cargo taint` command rather quickly, so let me know if this is useful or desired.
> 
> Note that the kernel does not use Cargo at the moment.

Right, I forgot about that, but if anything it slightly simplifies the work.
> 
>> PS: I gleaned from other threads that there’s a Zulip as well, would it be possible to get an invite?
> 
> Of course, invitation sent -- welcome!
> 
> Cheers,
> Miguel

Re: Taint Analysis for Kernel Rust

[Miguel Ojeda]

On Tue, May 17, 2022 at 12:39 PM Xavier Denis <xldenis@lri.fr> wrote:
>
> Is there any interest in a prototype? Doesn’t the kernel already use a similar system for C?

Definitely, any analysis that is able to statically prove some
properties would be ideal, and any improvement over what the kernel
has now (whether for C or for Rust) would be welcome.

For debugging sleeps in atomic contexts, there is `might_sleep()` and
friends: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kernel.h#n131

Another area that could be interesting to look at for feasibility of
new analyses is locking correctness, see lockdep:
https://www.kernel.org/doc/html/latest/locking/lockdep-design.html

> Right, I forgot about that, but if anything it slightly simplifies the work.

Indeed.

Cheers,
Miguel