Rust in the kernel

Rust in the kernel

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

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.

So, interested volunteers should begin organizing :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Rust in the kernel

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

On Thu, Jun 30, 2022 at 12:37:54PM -0400, Leo Famulari wrote:
> Within Guix, we'll need to adapt our kernel build processes in order to
> support this.

An update on GCC support for Rust:

https://lwn.net/Articles/899385/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Rust in the kernel

[Ludovic Courtès]

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

Re: Rust in the kernel

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust in the kernel

[jbranso]

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.

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.

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

Re: Rust in the kernel

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust in the kernel

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

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

Why "address spaces" is a revolutionary technology?  All kernels (except
the "Hello, World!" ones) use it.

By the way, what basic features are lacking (read available) in the Hurd
port?  Last time when I checked the pre-built disk image, I found that
it completely breaks after a reboot.  I mailed at help-guix list[1],
but got no response.

[1]: https://lists.gnu.org/archive/html/help-guix/2021-09/msg00043.html


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust in the kernel

[jbranso]

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

Re: Rust in the kernel

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 4467 bytes --]

jbranso@dismail.de writes:

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

Yes, I know that Mach is one of the slowest kernels.  BTW, what's the
status of Viengoos?

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust in the kernel

[Nathan Dehnel]

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

This was done with an older L4 (Pistachio, I think) that lacked
capabilities in the kernel. Doing it with SEL4 has not been thoroughly
investigated.

Re: Rust in the kernel

[Nathan Dehnel]

>BTW, what's the
status of Viengoos?

The author put it on indefinite hiatus and no one else has the
expertise (and/or interest) to continue to work on it.

Re: Rust in the kernel

[jbranso]

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

> jbranso@dismail.de writes:
> 
>> 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.
> 
> Yes, I know that Mach is one of the slowest kernels. BTW, what's the
> status of Viengoos?

I believe that Viengoos is essentially dead.  I do not believe
that anyone is actively working on it.  

More info is available here:

http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html

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

Re: Rust in the kernel

[Ludovic Courtès]

Hi,

Akib Azmain Turja <akib@disroot.org> skribis:

>> (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’.
>>
>
> Why "address spaces" is a revolutionary technology?  All kernels (except
> the "Hello, World!" ones) use it.

That was an ironic remark from my part.  Virtual memory management and
address spaces are not revolutionary at all: that’s how we protect
processes from stomping onto each other’s toes since the 70’s.

If the goal really is to improve OS reliability through a
multi-person-year effort, then I believe pouring that effort into a
microkernel-based design would be more fruitful.  My 2¢!

Ludo’.

Re: Rust in the kernel

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Akib Azmain Turja <akib@disroot.org> skribis:
>
>>> (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’.
>>>
>>
>> Why "address spaces" is a revolutionary technology?  All kernels (except
>> the "Hello, World!" ones) use it.
>
> That was an ironic remark from my part.  Virtual memory management and
> address spaces are not revolutionary at all: that’s how we protect
> processes from stomping onto each other’s toes since the 70’s.
>
> If the goal really is to improve OS reliability through a
> multi-person-year effort, then I believe pouring that effort into a
> microkernel-based design would be more fruitful.  My 2¢!
>
> Ludo’.

I agree, but it's very hard because the hardware vendors tend to keep
things secret, and unfortunately there isn't enough people interested
in Hurd.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]