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

Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

github.com

Post reply on HN
Print view View original

141–150 of 234 posts

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#141

Post by lmm »

bcrl wrote: post #61
yjftsjthsd-h wrote: post #43

Earlier quoted context omitted.

Oh sure, the user-space ABI is stable; I meant kernel-space. Although I realize now that I failed to write that explicitly.

The past 30 years of the Linux kernel's evolution has proven that there is no need for a stable kernel ABI. That would make refactoring, adding new features and porting to new platforms exceedingly difficult. Pretty much all of the proprietary kernel modules have either become open source or been replaced by open source replacements. The Linux community doesn't need closed source kernel modules for VMWare anymore, an…

> The past 30 years of the Linux kernel's evolution has proven that there is no need for a stable kernel ABI.

My experience of using Linux and having devices that used to work become unsupported suggests just the opposite.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#142

Post by GoblinSlayer »

jeroenhd wrote: post #119
KingOfCoders wrote: post #88

Earlier quoted context omitted.

I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.

Lifetime tracking and ownership are very difficult. That's why languages like C and C++ don't do it. It's also why those languages needs tons of extra validation steps and analysis tools to prevent bugs. Arc is nothing more than reference counting. C++ can do that too, and I'm sure there are C libraries for it. That's not an admission of anything, it's actually solving the problem rather than ignoring it and hoping i…

Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result>? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result> from an average function call?

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#143

Post by senko »

m463 wrote: post #80
loeg wrote: post #46

Earlier quoted context omitted.

More recently, in a similar vein: > Torvalds seemed optimistic that "some clueless young person will decide 'how hard can it be?'" and start their own operating system in Rust or some other language. If they keep at it "for many, many decades", they may get somewhere; "I am looking forward to seeing that". Hohndel clarified that by "clueless", Torvalds was referring to his younger self; "Oh, absolutely, yeah, you hav…

"You are enthusiastic and write kernel device drivers in rust. Write a device driver for an Intel i350 4 Port gigabit ethernet controller"

You jest, but I believe @tptacek is using an LLM (ChatGPT?) to understand the details of various Linux kernel subsystem and has said it works quite well for the task.

It's not a great jump from that to "port Linux device driver for XYZ to this new OS in Rust". Won't be perfect but a lot less hassle than doing it from scratch.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#145

Post by rcxdude »

lmm wrote: post #139
linsomniac wrote: post #68

Earlier quoted context omitted.

I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.

Those workloads would probably be better off as unikernels that can run directly on the VM, avoiding the question of which kernel to use entirely.

There's a difference between "want to run an application with as little extra move parts on a VM" and "want to take an existing system and swap out for a kernel with some better properties, even if it means needing to run it in a VM"

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#146

Post by oefrha »

prmoustache wrote: post #121

> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3 Is that the new generation of curl | bashism in action?

Hardly different from downloading random binary installers and executing them. Or random source distributions and (sudo) make install. Or npm/pip/cargo/etc. install random packages. Before anyone mentions distros and package managers, as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically. We’ll yank something after the fact if you report a malicious update, sure.

curl | bash has an actual problem: potential execution of an incomplete script (which can be mitigated with function calling). And there’s the mostly theoretical problem of the server being pwned / sending malicious code just to you (which of course also applies to any other unsigned channel). Arbitrary code execution is never a problem unique to it, but people dunk on it all the time because they saw another person dunking on it in the past.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#147

Post by rcxdude »

yjftsjthsd-h wrote: post #75
linsomniac wrote: post #68

Earlier quoted context omitted.

I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.

How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)

If it's written in rust, you might expect less security vulnerabilities (especially if the codebase is also smaller: NB this is potentially counterbalanced by the many eyes on linux). Maybe there would be some extra features you find useful.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#148

Post by rcxdude »

wg0 wrote: post #110
baq wrote: post #93

Earlier quoted context omitted.

If you’re writing C and don’t track ownership of values, you’re in a world of hurt. Rust makes you do from day one what you could do in C but unless you have years of experience you think it isn’t necessary.

Okay, I think it is is more like Typescript. You hate it but one day you just write small JS program and convert it to Typescript to discover that static analysis alone had so many code paths revealed that would have resulted in uncaught errors and then you always feel very uncomfortable writing plain Javascript. But what about tools like valgrind in context of C?

Valgrind can only tell you about issues that your testcases exercise. It doesn't provide the same guarantees as static checking of memory safety invariants. But, if you're really concerned (especially about unsafe code), belt-and-bracers is a good strategy, and valgrind will work with rust binaries as well. Rust also has a tool called MIRI which can similarly flag up issues in testcases (it's effectively an interpreter for the intermediate representation in the compiler, and it can detect undefined behaviour even if the compiled assembly would happen to look OK. Still has the same limitation of needing extensive testcases though)

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#149

Post by rcxdude »

guenthert wrote: post #115
cgh wrote: post #34

Earlier quoted context omitted.

Interesting, it's been awhile since I looked at this stuff so I did a little searching and found this: https://www.diva-portal.org/smash/get/diva2:1789103/FULLTEXT... Their conclusion is io_uring is still slower but not by much, and future improvements may make the difference negligible. So you're right, at least in part. Given the tradeoffs, DPDK may not be worth it anymore.

"io_uring had a maximum throughput of 5.0 Gbit/s " Wut? More than 10 years ago, a cheap beige box could saturated a 1Gbps link with a kernel as it came from e.g. Debian w/o special tuning. A somewhat more expensive box could get a good share of a 10Gbps link (using Jumbo frames), so these new results are, er, somewhat underwhelming.

Packet size does affect the throughput quite a lot, though. The tests in the paper are without jumbo frames (I do agree though, that the results in that paper can't really be described as 'close', when io_uring is 1/5 the speed, only achieves that at the largest packet size, and has much more packet loss under those conditions)

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#150

Post by rcxdude »

hkalbasi wrote: post #53

> In the framekernel OS architecture, the entire OS resides in the same address space (like a monolithic kernel) and is required to be written in Rust. However, there's a twist---the kernel is partitioned in two halves ... the unprivileged Services must be written exclusively in safe Rust. Unprivileged services can exploit known compiler bugs and do anything they want in safe Rust. How this affects their security mod…

I think it's not so much intended as a "you can allow arbitrary untrusted code to run as an unprivileged service" and more "a buggy unprivileged service won't compromise the whole system".
Post reply on HN