Hacker News Reader

Comment by nsajko | Hacker News Reader

You have no proof that writing a Linux-like kernel in Rust would result in fewer bugs, or even that it is feasible at all (what with writing even linked lists being difficult).

View on HN

>or even that it is feasible at all (what with writing even linked lists being difficult).

You're right, a Rust OS kernel probably wouldn't use linked lists but I'm not sure why that is a barrier to making a kernel. The redox[0] kernel is written entirely in Rust.

[0] https://www.redox-os.org/

That is why I said "Linux-like". Redox has a microkernel design, which presumably makes writing the drivers in Rust much easier at the expense of some throughput and latency.

I mean it is obviously possible. Rust can do anything that C can do, literally.

Your question is mixing safe and unsafe Rust as if they're one and the same. What I think you meant to ask is "Can Linux be implemented in safe Rust?" And my answer would be "likely not, but the goal is to limit the number/size of unsafe sections, so that they can be QA-ed harder and bugs discovered."

When you write C/C++, 100% of that codebase is unsafe. When you write Rust, even a kernel, should be 80/20 safe/unsafe or less. That's where the improvements come from.

> When you write C/C++, 100% of that codebase is unsafe.

Don't you think that statement is a bit over-the-top ? Large parts of C/C++ codebases are just as safe as the equivalent Rust code, as it doesn't do any pointer/memory manipulation.

For example, how is making a os system call in Rust any safer than the equivalent call in C ?

If you mean literally writing

    asm!("
        mov eax,1  ; system call number (sys_exit)
        int 0x80  ; call kernel
    ")

Obviously both are equally unsafe, also obviously both are extremely rare and not "large parts" of any program whatsoever (unless you're writing your program directly in assembly).

If you mean using the wrapper libraries that typically wrap system calls. Rust removes all sorts of possible fuckups. For instance in C one might write

    ssize_t bytes = read(some_file, buf, nbyte);

and if buf is null or a dangling pointer or nbyte is greater than the size of the allocation of buf you get undefined behavior. Or if afterwards you write

    printf("%s", buf);

and you forgot that read doesn't necessarily return a null terminated string you get undefined behavior. And so on and so forth.

In rust you would write something like

    let mut buf = [0; nbyte];
    let bytes = some_file.read(&mut buf)?;

and buf can't possibly be null or dangling and you can't possibly have messed up the length of the array because the abstractions checked that for you.

Afterwards if we were to write

    println!("{}", buf);

Well it will fail to compile... because buf isn't a string... and doesn't otherwise implement Display. But if we were to try to match the C code exactly and write one of

    stdout().write_all(buf)?;
    println!("{}", str::from_utf(&buf)?);

the second one would return an error if it wasn't a utf8 string, but neither would ever result in undefined behavior/security vulnerabilities.

(And yes, both of those are probably bugs in most programs, since you probably want to print buf[.. bytes] not buf. But bugs aren't security vulnerabilities. Also in real code I expect you would use read_to_string() if you were going to print it, which eliminates this potential bug too)

You are oversimplifying. Both of the languages being Turing-complete does not imply Rust being as good a choice for talking to hardware as C is. What I am getting at is: the imaginary Rust replacement for Linux may have ten times as much code as Linux does and be unmaintainable.

Rust's safe mode eliminates the possibility for some classes of bugs, but this still does not imply the hypothetical Rust kernel would be more reliable than Linux. What I am getting at is: Rust is a quite different language than C, and the hypothetical Linux replacement in Rust could be buggier than Linux.

Regarding the above, my message is not that I know that Rust is worse than C for some applications; but rather that Rust fans and C haters are not even addresing those points. pjmlp deftly avoided saying anything explicitly, but still he should for the sake of the discussion and decency at least try to address those points while making such distasteful comments as "Naturally it was only due to the current shortage of those mythical C developers that never make memory corruption mistakes.".

Linked lists are difficult, but can be abstracted behind a library.

Here's a no_std intrusive linked list library I've used in kernel environments. https://docs.rs/intrusive-collections/0.9.0/intrusive_collec...

It's not like you reimplement linked lists in every driver in the Linux kernel either; you include linux/list.h like everyone else.

But "use rust" seems to be obvious enough as a solution that you simply assumed that's the direction GP is going? :)

Honest question though: shouldn't it be possible to only write single kernel modules (like drivers) in rust, without switching out the entire OS at once?

Answering myself here: of course someone else already did that. :)

https://github.com/fishinabarrel/linux-kernel-module-rust

No I don't, but there are surely proofs in Ada, PL/I, PL/S, NEWP.

Well... I'm going to guess that the largest kernel written in PL/I was at least one order of magnitude smaller than Linux, and probably two orders of magnitude smaller. I'm also going to guess that it was never subject to a 2020 state-of-the-art fuzzer. (I'm even going to guess that it never had USB support.) So, while you may have a point, your comparison is hardly apples-to-apples.

I bet IBM i does have a couple of USB ports.

And Unisys sells ClearPath MCP to three letter agencies over UNIX for a reason.

Reply on news.ycombinator.com