
Booting to Rust - dbaupp
http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
======
haberman
Great article -- just the kind of meaty technical content I love seeing here.
Also good to know Rust is living up to its goal of being a fully-fledged
systems programming language.

~~~
freehunter
Agreed. I'd love to see a "build an OS with Rust" tutorial.

~~~
cmrx64
What would you want to see in such a tutorial? A lot goes into even the most
barebones functional operating systems.

~~~
daniel-levin
I'd go crazy for something along the lines of xv6 [1]. xv6 is a modified Unix
V6 that is used to teach the principles of operating systems. Its source code
is small and well written. A rust analogue would be awesome

[1]
[http://pdos.csail.mit.edu/6.828/2012/xv6.html](http://pdos.csail.mit.edu/6.828/2012/xv6.html)

~~~
cmrx64
I'll see what I can do

------
daurnimator
Makes me sad to realise just how much of EFI, the new universal standard, was
dictated by Microsoft norms (UTF16, binary format, etc)

~~~
dbaupp
Yeah, the author even had to add support for the appropriate calling
convention (win64) to the compiler[1] to get it to work.

[1]:
[https://github.com/mozilla/rust/pull/10527](https://github.com/mozilla/rust/pull/10527)
not yet landed.

~~~
orf
That was hardly challenging, look at the number of changes.

~~~
dbaupp
I didn't say it was challenging. (And yes, most of the changes are actually
fixing a different bug, not just adding support for the new ABI.)

------
chalst
The ease and flexibility of this kind of thing is reason to expect UEFI
viruses will be more common than viruses targetting earlier firmware.

~~~
andrewaylett
Leading to Secure Boot, pretty much.

------
aray
Nice writeup! It's interesting to see the similarities between Booting to Rust
and booting Go on baremetal.

~~~
dbaupp
You can't say something interesting like that without a link to a Go example
for the rest of us to see the similarities too. :)

~~~
aray
Other commenters beat me to the first two examples, though there's more.

GoFY (which hilariously I'm a contributor on) was probably the closest
analogy; it booted on x86. Russ Cox's did as well, but it was removed from the
go tree years ago when it bitrotted.

Really it boils down to 1) custom linker scripts/targets and 2) a custom "OS"
target that emulates syscalls/etc

I've done it a couple times (on ARM-based embedded devices), I end up throwing
it out every time. Should get a proper writeup I suppose.

~~~
dbaupp
Hm, those two seem vastly more complicated, with extra C and ASM rather than
just plain Go.

------
tinco
So I'm a bit confused, the article says the code is ran in 64bit mode, but
before virtual memory is turned on. How is that possible?

I remember from the OSDev wiki that the only way to get a processor in 64 bit
mode was by first turning on virtual memory. I remember because I was
disappointed by that, it seems unnecessary.

Doesn't UEFI play by these rules, or am I misunderstanding?

~~~
ivanca
"64-bit UEFI understands long mode, which allows applications in the pre-boot
execution environment to have direct access to all of the memory using 64-bit
addressing."

Source:
[http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Int...](http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface)

~~~
haberman
I believe that "long mode" is just the name for the native 64-bit mode of
these processors; ie. what you'd normally run 64-bit Linux under, with the MMU
enabled.

------
tmzt
It would be interesting to see Rust bindings for coreboot's libfirmware.

