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

61–70 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#61

Post by NooneAtAll3 »

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]

>> Memory safety isn’t why containers are considered insufficient as a security boundary.

> Memory safety is the primary issue with containers as a security boundary.

"No it isn't" "Yes it is" "No it isn't" "Yes it is"

Re: Maestro: A Linux-compatible kernel in Rust

#62

Post by pas »

goodpoint wrote: post #34

Writing alternatives to GPL software under MIT/Apache licenses is really harmful for the FOSS ecosystem. We need to protect end users from more and more proprietarization, tracking and privacy breaching, SaaS and untrusted IoT devices.

The road paved with good intentions and all.

Sure, users are 1-bit entities in need of protection, no questions 'bout that, but also given that premise they are best served by good software that helps them get their job done. If a kick ass GPL software can do that, great. They will even pay for it. If not? They will pay for the non-OSI one that bundles the GPL and will laugh at GPL enforcement attempts.

Licenses are intellectually cute, but unless it's well-enforced AGPL3++ it doesn't matter much. (See the recent thread about 3D printer https://news.ycombinator.com/item?id=38768997 )

Re: Maestro: A Linux-compatible kernel in Rust

#63

Post by insanitybit »

jmakov wrote: post #55
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 ?

Kata is an attempt at solving this problem. There are problems:

1. If using firecracker then you can't do nested virtualization

2. You still have the "os in an os" problem, which can make it operationally more complex

But Kata is a great project.

Re: Maestro: A Linux-compatible kernel in Rust

#64

Post by insanitybit »

jvanderbot wrote: post #57
fires10 wrote: post #54

Earlier quoted context omitted.

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.

The premise of my post was "imagine a memory safe kernel". I repeatedly use the word "imagine".

Re: Maestro: A Linux-compatible kernel in Rust

#65

Post by maayank »

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…

I’m interested of reading more. Where can I find the blog posts?

Re: Maestro: A Linux-compatible kernel in Rust

#66

Post by RHSeeger »

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 expect it's likely more of "memory safety in a language doesn't make it _safe_, it makes it less vulnerable". It removes _some_ issues, in the same way that a language with static types removes some ways a program can be wrong, it doesn't make it correct.

Re: Maestro: A Linux-compatible kernel in Rust

#67

Post by t8sr »

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]

> Memory safety is the primary issue with containers as a security boundary.

I don't know where you're getting your information, but this is NOT the consensus on the LMKL, among most Linux kernel people or at any serious large scale tech company.

If you wish to learn about this stuff, lwn.net has a good series of articles on the problems people are actually working on. Most of the problems are related to namespace confusion, privilege escalation through, e.g. block-level access to the filesystem, etc.

> Sometimes the issues are not memory safety ones! But many, most are.

Huge citation needed. In 15 years of security, 8 in Linux kernel security, I have seen maybe one practical exploit related to containers that boiled down to a C-level memory issue.

> That's on you, but I'd be happy to explain more to you if you have questions.

No, you're very confidently stating things that are at the very least debatable. This thread has people doing kernel security as a day job.

Re: Maestro: A Linux-compatible kernel in Rust

#68

Post by jvanderbot »

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]

This is getting a bit defensive. I think people are interpreting your post as saying all safety is guaranteed by using memory safety, but you rightly walk it back in comments to mean it addresses "primary" security problems.

That's it.

Re: Maestro: A Linux-compatible kernel in Rust

#69

Post by ho_schi »

cmrdporcupine wrote: post #22
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…

I like Rust and work in it fulltime, and like its memory-safety aspects but I think it's a bit of a stretch to be able to claim memory safety guarantees of any kind when we're talking about low-level code like a kernel. Because in reality, the kernel will have to do all sorts of "unsafe" things even just to provide for basic memory management services for itself and applications, or for interacting with hardware. You…

Yep. And tooling to secure C improved a lot in recent years. The Address-Sanitizer is a big improvement. I’m looking forward that C++ improves as language itself because it was already improved (smart-pointers, RAII, a lot of edge cases regarding sequencing) and they seem to be willing to modify the actual language. This opens a path for project to migrate from C to C++. A language inherits a lot from its introduction (strength/weak) but also changes a lot.

Every interaction with hardware (disk, USB, TCP/IP, graphics…) need to do execute unsafe code. And we have firmware. Firmware is probably a underestimate issue for a long time :(

Aside from errors caused by undetected undefined behavior all kinds of errors remain possible. Especially logic errors. Which are probably the biggest surface?

Example:

https://neilmadden.blog/2022/04/19/psychic-signatures-in-jav...

Honestly I struggle to see the point in rewriting C++ code with Java just for the sake of doing it. Probably improving test coverage for the C++ implementation would have been less work and didn’t created the security issue first.

That being said. I want to see an #unsafe and #safe in C++. I want some hard check that the code is executing only defined. And modern compilers can do it for Rust. Same applies to machine-dependent/implementation defined code which isn’t undefined but also can be dangerous.

Re: Maestro: A Linux-compatible kernel in Rust

#70

Post by insanitybit »

maayank wrote: post #65
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…

I’m interested of reading more. Where can I find the blog posts?

https://web.archive.org/web/20221130205026/graplsecurity.com...

The company no longer exists so you can find at least some of them mirrored here:

https://chompie.rip/Blog+Posts/

The Firecracker, io_uring, and ebpf exploitation posts.

Chompie was my employee and was the one who did the exploitation, though I'd like to think I was at least a helpful rubber duck, and I did also decide on which kernel features we would be exploiting, if I may pat myself on the back ever so gently.

Post reply on HN