7 ms·
Booting to Rust
- haberman 13y agoGreat 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 13y agoAgreed. I'd love to see a "build an OS with Rust" tutorial.
- cmrx64 13y agoWhat would you want to see in such a tutorial? A lot goes into even the most barebones functional operating systems.
- daniel-levin 13y agoI'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 13y agoI'll see what I can do
- codingbinary 13y agoCount me in. I'll help with the coding.
- girvo 13y agoI'm more super interesting in diving into EFI! In highschool, I wrote a tiny toy kernel, running solely in 16bit real mode. Quite fun, but I wanted to go further and my knowledge was lacking, although the project did help me learn a lot of ASM. The OP has shown that I could do all sorts of cool stuff going straight into x64 without all the incantations! That's actually super exciting, and makes me hate EFI a little less ;) I'm going to go play, I think! I wonder what Lisp would be the best candidate here...
- xradionut 13y agoI'd rather see Oberon ported to a modern machine. :)
- pjmlp 13y agoJoin efforts with the Active Oberon team at ETHZ. http://www.ocp.inf.ethz.ch/wiki/ http://www.ocp.inf.ethz.ch/wiki/ There are still some students and external guys keeping the ports going. http://www.ocp.inf.ethz.ch/forum/index.php/board,4.0.html http://www.ocp.inf.ethz.ch/forum/index.php/board,4.0.html Nowadays, I think Oberon spirit will live in Rust, D, Go, C#. :)
- xradionut 13y agoHas any of Oberon's "spirit children" been used for a full fledged OS yet?
- pjmlp 13y agoJust kernel level, or partial state projects that were abandoned. D - Xomb - http://wiki.xomb.org/index.php?title=Main_Page http://wiki.xomb.org/index.php?title=Main_Page Go - TinyGo - http://code.google.com/p/tinygo/ http://code.google.com/p/tinygo/ C# - Singularity - http://singularity.codeplex.com/ http://singularity.codeplex.com/, Cosmos - http://cosmos.codeplex.com/ http://cosmos.codeplex.com/ The main problem is lack of support, it is a very big effort to create an OS and it is very easy to turn attention to other stuff. Linux and BSD distributions wouldn't have reached the state they enjoy nowadays, without the help of the existing UNIX toolset and investment of companies interested in seeing the projects succeed.
- eholk 13y agoResponding to pjmlp, a cool project I saw recently that's related to the ones you mentioned is Unikernels [1]. They noticed that a challenge faced by a lot of those projects is hardware support--each OS has to ship with a huge set of drivers to be widely usable. They sidestep this by targeting a VM, which exposes a single hardware interface no matter what it's running on. [1]: http://anil.recoil.org/papers/2013-asplos-mirage.pdf http://anil.recoil.org/papers/2013-asplos-mirage.pdf
- tinco 13y agoSo 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 13y ago"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_Interface http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Int...
- haberman 13y agoI 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.
- haberman 13y agoI think "turning on the MMU" is something a bit different than "turning on virtual memory." The former just means that all addresses are translated from virtual->physical, while the latter implies more abstraction: virtual memory can be overcommitted, pages might not be resident. This is just a guess, but I'd wager that UEFI has the MMU enabled, but with an identity mapping that maps all virtual addresses to the same physical address.
- aray 13y agoNice writeup! It's interesting to see the similarities between Booting to Rust and booting Go on baremetal.
- dbaupp 13y agoYou can't say something interesting like that without a link to a Go example for the rest of us to see the similarities too. :)
- _mhr_ 13y agoWell, there's this: http://code.google.com/p/gofy/ http://code.google.com/p/gofy/
- adsche 13y agoI was interested in this as well and found this commit[1] by Russ Cox. README has details on running it inside bochs. [1] http://code.google.com/p/go/source/detail?r=ffbf0900a2 http://code.google.com/p/go/source/detail?r=ffbf0900a2
- aray 13y agoOther 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 13y agoHm, those two seem vastly more complicated, with extra C and ASM rather than just plain Go.
- chalst 13y agoThe ease and flexibility of this kind of thing is reason to expect UEFI viruses will be more common than viruses targetting earlier firmware.
- andrewaylett 13y agoLeading to Secure Boot, pretty much.
- daurnimator 13y agoMakes me sad to realise just how much of EFI, the new universal standard, was dictated by Microsoft norms (UTF16, binary format, etc)
- dbaupp 13y agoYeah, 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 13y agoThat was hardly challenging, look at the number of changes.
- dbaupp 13y agoI 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.)
- eholk 13y agoTo be fair, Rust probably would have needed this for some other reason in the future. I see this more as making Rust a more complete language.
- Xylakant 13y agoI fail to see the major issue here: The standard needed to specify those points, otherwise one EFI implementation would expect UTF8, another ASCII and yet another UTF-16. The calling conventions, the binary format and UTF-16 are widely supported across platforms and known. Windows calling conventions are probably more widely implemented than any other (since the popular linux compilers can cross compile to win and not the other way round). Just because Rust had no support for the windows calling conventions that doesn't imply that C for example has the same problem. UTF-16 is used in different places as well, notably in Java. No problem here as well. It also has the major advantage of being a fixed width encoding over UTF8. That might be fairly useful when your code doesn't have full OS and library support when running. All in all: It's probable that Microsoft influenced the standard here, but there's also sufficient technical reasons for those choices. There's other places where Microsofts influence on the standard is a much bigger problem.
- tmzt 13y agoIt would be interesting to see Rust bindings for coreboot's libfirmware.