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

Rewrite Linux Kernel in Rust?

dominuscarnufex.github.io

Post reply on HN
Print view View original

41–50 of 133 posts

Re: Rewrite Linux Kernel in Rust?

#41

Post by delhanty »

im_down_w_otp wrote: post #40
delhanty wrote: post #39

Earlier quoted context omitted.

That sounds like another nice idea. What happened to your project?

Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.

Thank you.

I was just reading your comments and found this one:

>Erlang: the general disinterest of Ericsson and the hapless stewardship​ of Erlang Solutions.

Is that related to the reason that BEAM is no longer part of your day job?

The reason I ask is that I am thinking of starting a new project with BEAM, maybe some Rust or C++ and wondering whether Elixir has taken over from Erlang due to the disinterest of Ericsson.

Re: Rewrite Linux Kernel in Rust?

#42

Post by rdtsc »

spc476 wrote: post #30
rdtsc wrote: post #13

Earlier quoted context omitted.

Right, but the mnemonic reads better in AT&T then "move 5 to register eax" and Intel seems backwards.

It's what you get used to. I'm used to x86 being "dst,src". It never bothered me that on the Motorola 68000 it went "src,dst" as, it was what it was. Intel defined it one way, Motorola another way [1]. My gripe with AT&T style (and it's called AT&T because K&R wrote their assembler that way) is that it uses sigils to mark registers (something I've never seen any other assembler do) and specifically broke with the man…

I learned on Intel and that's the only I can use. Just pointing out that reading the expression makes more sense in AT&T style so might be why they did it that way.

And always wondered why the need for % in AT&T for registers. It seems like there would no ambiguity based on instruction.

Re: Rewrite Linux Kernel in Rust?

#43

Post by amluto »

> (*pointer).handle();

Eek! That is, indeed, unsafe.

But this shouldn't be messing with the entry asm at all. Just add your new syscall to the syscall table, just like any other syscall.

Re: Rewrite Linux Kernel in Rust?

#44

Post by troutwine »

im_down_w_otp wrote: post #40
delhanty wrote: post #39

Earlier quoted context omitted.

That sounds like another nice idea. What happened to your project?

Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.

Don't suppose your work is online? I'd be interested to read your patchsets.

Re: Rewrite Linux Kernel in Rust?

#45

Post by saghm »

im_down_w_otp wrote: post #4

Pretty cool. I decided to take a similar path in trying to improve/ensafen parts of the BEAM VM by finding small chunks I could rewrite in Rust from C. Most of the headache was build toolchain integration stuff. I did manage to get a few simple things slotted in that appear to work transparently, which made me hopeful for future more complicated things to play with like new process mailbox implementations, etc. Anywa…

OT: I really like the word "ensafen", and I'm totally going to borrow it for future use

Re: Rewrite Linux Kernel in Rust?

#46

Post by nickpsecurity »

kbenson wrote: post #9

Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it bein…

"I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how."

It's a very detailed guide of how key components were incrementally improved in some way with actual source. That's almost always a good thing since it ranges from beneficial for intended goal to helping people learn things when it wasn't.

Re: Rewrite Linux Kernel in Rust?

#47

Post by nickpsecurity »

delhanty wrote: post #38
polygot wrote: post #10

This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.

If there were a fork and the fork were to gain momentum it might be not be up to Linus. A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper. There would also be the attraction of learning Rust in a very real world context. edit:s/in/it

This is a good argument if a massive amount of effort was piled into this with lots of refactoring on top of it. Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything.

Re: Rewrite Linux Kernel in Rust?

#48

Post by AstralStorm »

hyperpape wrote: post #33
kbenson wrote: post #22

Earlier quoted context omitted.

> I kind of expect it to follow the order assignment does when I write in C++, C#, etc. There is no special precedence that should be applied to C. Similarity to C only imparts benefits to those that are fimilar with C-like languages or variants that follow that structure. That ends up being a lot of people because of how popular C and variants have been, but that's doesn't inherently make it better . It's sort of a…

This does raise the question: which languages other than AT&T assembly put the value first?

AT&T syntax puts the operator first, not the value. AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Many kinds of S expressions result in similar code. That would mean Lisp derivatives.

Re: Rewrite Linux Kernel in Rust?

#49

Post by jlrubin »

This was a fun write up.

On the off chance the author is reading the comments here, there are a couple security features they need to add for it to be more complete (I'm probably missing some things).

1) They should add a call to access_ok(VERIFY_WRITE, pointer, mem::size_of()) in rust_syscall_handle to ensures that the user space pointer points to valid userspace memory of the right shape for the syscall type.

2) They should sanitize (hopefully, using some zero-cost method) the Syscall type to guarantee that it is well-formed before calling handle. If the userspace constructs some normally impossible to construct Syscall, it's unclear how a rust match pattern handles it (i.e., if an enum has only 3 types and you pass in a falsely constructed variant with tag 100 is match guaranteed not to just be using a jump table and accidentally jump 100 instructions?)

Re: Rewrite Linux Kernel in Rust?

#50

Post by nickpsecurity »

lacampbell wrote: post #20

What is the rust communities obsession with suggesting (threatening?) rewrites of battle tested C programs that have been around for decades? Now a kernel for a new OS, that'd be something.

I provoked some solid answers from team members on that in this thread:

https://lobste.rs/s/ldnlos/have_you_considered_rewriting_it_...

Skade even dropped a HOWTO in one comment on replicating much of their community results in other projects. There's plenty of data from team members to look at there where I'll let the rest of you make decisions about it on your own.

Post reply on HN