5 ms·

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 b

by nsajko 6y ago

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

jabedude 6y ago
>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/ https://www.redox-os.org/
- nsajko 6y ago
  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.
black_puppydog 6y ago
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?
- black_puppydog 6y ago
  Answering myself here: of course someone else already did that. :) https://github.com/fishinabarrel/linux-kernel-module-rust https://github.com/fishinabarrel/linux-kernel-module-rust
pjmlp 6y ago
No I don't, but there are surely proofs in Ada, PL/I, PL/S, NEWP.
- AnimalMuppet 6y ago
  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.
  - pjmlp 6y ago
    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.
monocasa 6y ago
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_collections/ 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.
Someone1234 6y ago
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.
- pml1 6y ago
  > 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 ?
  - gpm 6y ago
    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)

by nsajko 6y ago

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

jabedude 6y ago

>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/ https://www.redox-os.org/

nsajko 6y ago
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.

black_puppydog 6y ago

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?

black_puppydog 6y ago
Answering myself here: of course someone else already did that. :) https://github.com/fishinabarrel/linux-kernel-module-rust https://github.com/fishinabarrel/linux-kernel-module-rust

pjmlp 6y ago

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

AnimalMuppet 6y ago
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.
- pjmlp 6y ago
  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.

monocasa 6y ago

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

Someone1234 6y ago

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.

pml1 6y ago
> 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 ?
- gpm 6y ago
  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)