Re: Rust kernel policy

[Jarkko Sakkinen <jarkko@kernel.org>]

On Thu, Feb 20, 2025 at 12:57:11PM +0100, Fiona Behrens wrote:
> Jarkko Sakkinen <jarkko@kernel.org> writes:
> 
> > On Wed, 2025-02-19 at 12:52 -0800, Bart Van Assche wrote:
> >> On 2/19/25 12:46 PM, Steven Rostedt wrote:
> >> > I do feel that new drivers written in Rust would help with the
> >> > vulnerabilities that new drivers usually add to the kernel.
> >> 
> >> For driver developers it is easier to learn C than to learn Rust. I'm
> >> not sure that all driver developers, especially the "drive by"
> >> developers, have the skills to learn Rust.
> >
> > IMHO, Rust is not that difficult to learn but it is difficult to
> > run.
> >
> > One point of difficulty for me still is the QA part, not really the
> > code. QuickStart discusses on how to install all the shenanigans
> > with distribution package managers.
> >
> > The reality of actual kernel development is that you almost never
> > compile/run host-to-host, rendering that part of the documentation
> > in the battlefield next to useless.
> >
> > Instead it should have instructions for BuildRoot, Yocto and
> > perhaps NixOS (via podman). It should really explain this instead
> > of dnf/apt-get etc.
> 
> What do you mean with via podman for NixOS?

I sometimes use NixOS to test more complex kernel configurations. See

https://social.kernel.org/notice/ArHkwNIVWamGvUzktU

I'm planning to use this approach to check if I could use that to
build efficiently kernels with Rust.

I've not been so far successful to do it with BuildRoot, which has
zeroed out any possible contributions for rust linux. Writing code
is like 5% of kernel development. Edit-compile-run cycle is the
95%.

> I do still have on my ToDo list to build and publish a better nix
> development shell for kernel with rust enabled, and could also add a
> section on how to build a NixOS iso in the same nix code.
> But sadly time is a finite resource and so did not yet got to it.

Please do ping me if you move forward with this. IMHO, why wouldn't
you contribute that straight to the kernel documentation? Right no
there are exactly zero approaches in kernel documentation on how
test all of this.

The best known method I know is to extend this type of example I
did year ago:

#!/usr/bin/env bash

set -e

make defconfig
scripts/config --set-str CONFIG_INITRAMFS_SOURCE "initramfs.txt"
yes '' | make oldconfig

cat > initramfs.txt << EOF
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/loop0 644 0 0 b 7 0
dir /bin 755 1000 1000
slink /bin/sh busybox 777 0 0
file /bin/busybox initramfs/busybox 755 0 0
dir /proc 755 0 0
dir /sys 755 0 0
dir /mnt 755 0 0
file /init initramfs/init.sh 755 0 0
EOF

mkdir initramfs

curl -sSf https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/busybox-static-1.36.1-r25.apk | tar zx --strip-components 1
cp busybox.static initramfs/busybox

cat > initramfs/init.sh << EOF
#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
sh
EOF

and then qemu-system-x86_64 -kernel arch/x86/boot/bzImage

It's sad really.

> 
> Fiona

BR, Jarkko