Re: Rust kernel policy

Fiona Behrens
2025-03-04T11:17:57Z

Jarkko Sakkinen <jarkko@kernel.org> writes:

> 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.

I do have a new pr open in the nix repo, it still needs some polishing
and gcc and all that. but it does work for me to build using clang and
also run kunit.

https://github.com/Rust-for-Linux/nix/pull/8

Thanks
Fiona

>
> 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