Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

51–60 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#51

Post by t8sr »

insanitybit wrote: post #6

A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…

Container vulnerabilities are rarely related to memory bugs. Most vulnerabilities in container deployments are due to logical bugs, misconfiguration, etc. C-level memory stuff is absolutely NOT the reason why virtualization is safer, and not something Rust would greatly improve. On the opposite end of the spectrum, you have hardware vulnerabilities that Rust also wouldn't help you with.

Rust is a good language and I like using it, but there's a lot of magical thinking around the word "safe". Rust's definition of what "safe" means is fairly narrow, and while the things it fixes are big wins, the majority of CVEs I've seen in my career are not things that Rust would have prevented.

Re: Maestro: A Linux-compatible kernel in Rust

#52

Post by opportune »

insanitybit wrote: post #49
opportune wrote: post #47

Earlier quoted context omitted.

Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in ru…

[flagged]

Respectfully, do you know what a container actually is? (I’m guessing you think it’s docker, which is a common misconception)

The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preventing these syscalls from doing bad shit.

Re: Maestro: A Linux-compatible kernel in Rust

#53

Post by thom »

peoplefromibiza wrote: post #44
insanitybit wrote: post #39

Earlier quoted context omitted.

I don't think it's that unfair, but I don't want to get into a whole thing about it, people get really upset about criticisms of the Linux kernel in my experience and I'm not looking to start my morning off with that conversation. We can agree that C was definitely the language to be doing these things in and I don't blame Linus for choosing it. My point wasn't to shit on Linux for its decisions, it was to think abou…

> where safety built in from the start Don't worry, in 30 years people will write the same thing about using Rust, assuming that Rust will still be in use 30 years from now.

Yeah, how naive we were building operating systems without linear and dependent types. Savages.

Re: Maestro: A Linux-compatible kernel in Rust

#54

Post by fires10 »

jvanderbot wrote: post #48
opportune wrote: post #47

Earlier quoted context omitted.

Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in ru…

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

Can you expound in this some? I am not fully grasping your point. Are you saying "building safe by default" is a bad thing or assuming "safe forever" is a bad thing. Or are you saying something entirely different?

Re: Maestro: A Linux-compatible kernel in Rust

#55

Post by jmakov »

insanitybit wrote: post #6

A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…

Hasn't Kata containers solved this probl: https://github.com/kata-containers/kata-containers ?

Re: Maestro: A Linux-compatible kernel in Rust

#56

Post by insanitybit »

t8sr wrote: post #51
insanitybit wrote: post #6

A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…

Container vulnerabilities are rarely related to memory bugs. Most vulnerabilities in container deployments are due to logical bugs, misconfiguration, etc. C-level memory stuff is absolutely NOT the reason why virtualization is safer, and not something Rust would greatly improve. On the opposite end of the spectrum, you have hardware vulnerabilities that Rust also wouldn't help you with. Rust is a good language and I…

> Container vulnerabilities are rarely related to memory bugs.

The easiest way to escape a container is through exploitation of the Linux kernel via a memory safety issue.

> C-level memory stuff is absolutely NOT the reason why virtualization is safer

Yes it is. The point of a VM is that you can remove the kernel as a trust boundary because the kernel is not capable of enforcing that boundary because of memory safety issues.

> but there's a lot of magical thinking around the word "safe"

There's no magical thinking on my part. I'm quite familiar with exploitation of the Linux kernel, container security, and VM security.

> the majority of CVEs I've seen in my career are not things that Rust would have prevented.

I don't know what your point is here. Do you spend a lot of time in your career thinking about hardening your containers against kernel CVEs?

Re: Maestro: A Linux-compatible kernel in Rust

#57

Post by jvanderbot »

fires10 wrote: post #54
jvanderbot wrote: post #48

Earlier quoted context omitted.

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

Can you expound in this some? I am not fully grasping your point. Are you saying "building safe by default" is a bad thing or assuming "safe forever" is a bad thing. Or are you saying something entirely different?

I said "the idea of using memory safe languages is great!" And "using memory safe languages does not eliminate attack surface". (It's pre coffee here so I appreciate your probe)

I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.

Re: Maestro: A Linux-compatible kernel in Rust

#58

Post by berkes »

dark-star wrote: post #37

What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. However, my guess is that the ones that are missing are the more complicated ones. The TTY layer, for example, looks rather basic at the moment. Getting this right will probably be a lot of work. So don't hold your breath for Maestro running your Linux applications in the next 3 years or so…

Is there maybe a subset of Linux applications that it could run soon? A proxy, nfs, some database server, http server, firewall?

I think it doesn't need to run Steam, libreoffice and Firefox to be useful. Many parts in a common server or microservices architecture are relatively simple in what they do and would probably benefit a lot from a safe, simple kernel.

Re: Maestro: A Linux-compatible kernel in Rust

#59

Post by jvanderbot »

meltyness wrote: post #50
jvanderbot wrote: post #48

Earlier quoted context omitted.

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

Just the other day they were full kum ba yah over a holiday-time-released feature that's likely going to greatly increase the likelihood of building race conditions and deadlocks. https://news.ycombinator.com/item?id=38721039

I know it's the curmudgeon NIMBY in me, and I love Rust and use it daily, but it's starting to feel like the worst of the JS crowd scribbled in grandpa's ANSI C books just to make him mad.

I am super happy with most features, but demand is demand and people demand runtimes. As a chimera it perfectly represents the modern world.

Re: Maestro: A Linux-compatible kernel in Rust

#60

Post by insanitybit »

opportune wrote: post #52
insanitybit wrote: post #49

Earlier quoted context omitted.

[flagged]

Respectfully, do you know what a container actually is? (I’m guessing you think it’s docker, which is a common misconception) The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preven…

> Respectfully, do you know what a container actually is?

I am extremely familiar with containers, the linux kernel, and virtual machines. In particular from a security perspective.

> The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself.

Namespaces, such as process namespaces, file namespaces, user namespaces, etc, will prevent a container from interacting with another container without even getting into the fact that you can leverage DAC to do so further.

Post reply on HN