Re: Rust in the kernel

[jbranso@dismail.de]

July 5, 2022 12:48 AM, "Akib Azmain Turja" <akib@disroot.org> wrote:

> jbranso@dismail.de writes:
> 
>> July 4, 2022 1:36 PM, "Akib Azmain Turja" <akib@disroot.org> wrote:
>> 
>>> Ludovic Courtès <ludo@gnu.org> writes:
>> 
>> Hi!
>> 
>> Leo Famulari <leo@famulari.name> skribis:
>>> The effort to use the Rust programming language within the Linux kernel
>>> is progressing and may be realized in the next few months:
>>> 
>>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e
>>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel
>>> 
>>> Within Guix, we'll need to adapt our kernel build processes in order to
>>> support this.
>>> 
>>> Although I help with updating and configuring the kernel builds, I won't
>>> be able to participate in the "Rust in the kernel" effort for Guix.
>> 
>> Understood…
>>> So, interested volunteers should begin organizing :)
>> 
>> Yup!
>> 
>> Now, concretely, how long will it take before key parts of the kernel
>> are written in Rust? Hopefully a long time, no? Per the article above,
>> it’s starting small, with Rust usage in well-defined locations.
>> 
>> This is not to say that we shouldn’t start organizing, but rather that
>> we still have a bit of time ahead.
>> 
>> (During that time, interested readers can also take a stab at improving
>> support for the Hurd, which relies on that revolutionary technology
>> called “address spaces” to ensure Memory Safety™ among other things!)
>> 
>> Ludo’.
>>> "Address spaces"! What's that? Sorry for asking without searching the
>>> internet first, but the Hurd designers are so creative that a few
>>> understand the concepts and join the community, so there is a little
>>> chance (if any) that I'll find any useful information on that.
>> 
>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html
>> 
>> The Hurd is built in a very modular fashion. Other Unix-like kernels
>> (Linux, for example) are also modular in that they allow loading
>> (and unloading) some components as kernel modules, but the Hurd goes
>> one step further in that most of the components that constitute the
>> whole kernel are running as separate user-space processes and are thus
>> using different address spaces that are isolated from each other.
>> This is a multi-server design based on a microkernel. It is not
>> possible that a faulty memory dereference inside the TCP/IP stack
>> can bring down the whole kernel, and thus the whole system, which
>> is a real problem in a monolithic Unix kernel architecture.
>> 
>> Some visual explantions:
>> 
>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg
>> 
>> The Hurd is on the right in this image.
> 
> Thanks, now I understand Ludo' was saying about virtual address space,
> achieved using paging.
> 
>> Essentially, if your fileserver somehow gets hacked, the attacker
>> cannot magically access your TCP/IP stack, because your TCP/IP is not
>> in the some "software zone" as your fileserver. So microkernels like
>> the Hurd are usually considered more secure and better designed
>> than monolithic kernels like Linux. However, monolithic kernels
>> will usually be faster than microkernels.
> 
> I know microkernels are theorically slow due to the heavy use IPC. But
> is it really impossible for well written microkernel to beat a well
> written monolithic kernel? L4 is super-fast, is it still slower than
> Linux?

Probably a little, but I am not an expert in that area.

GNU Mach, which is what the Hurd runs on.  Is slower that Linux.
There was an attempt to port the Hurd to L4 before.  It is
deemed not possible by the current hurd developers.


> 
>>> --
>>> Akib Azmain Turja
>>> 
>>> This message is signed by me with my GnuPG key. It's fingerprint is:
>>> 
>>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
> 
> --
> Akib Azmain Turja
> 
> This message is signed by me with my GnuPG key. It's fingerprint is:
> 
> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5