Re: Applying for GSoC 2022: Add Rust Support to EDK II
|
Hi Ayush,
Very interesting and intellectually stimulating, thank you! It makes sense that the Rust authors would opt to depend on libc for syscalls, at least on most UNIX designs there is an assumption that the library that implements the syscall interface *is* libc and any library that provides a syscall wrapper is just a different implementation of libc.
For UEFI, the closest equivalent we have to syscalls is the PEI services and UEFI boot services tables, which are basically just a bunch of C function pointers. Based on your research it sounds like in should be possible to build on top of some of this work that has already been done and create a version of std that is pure Rust with perhaps the exception of some C function pointer calls out to the UEFI services for memory allocation and whatnot. Memory allocation will be interesting because DXE provides a proper heap but PEI only allows pages (which are 4KB chunks of RAM) to be freed. As such it would probably make sense to build a Rust implementation of a heap that allocates and frees pages as necessary so that it will be possible to use std on both PEI and DXE.
With regard to Jiewen’s rust-firmware project, my personal opinion is that his approach is more long term and aspirational. Given that EDK II is now deployed on ~4 billion devices around the world, I don’t think a wholesale conversion from 0% Rust code to 100% pure Rust code across the entire industry is realistic. A much more pragmatic option in my opinion would be to allow some mix of C and Rust code to co-exist and if firmware implementations evolve towards a greater mix of Rust code over time than something like Jiewen’s proposal could become feasible. But in the short term my opinion is slowly introducing Rust over time is the only feasible option. I understand Jiewen’s reasons for preferring a 100% Rust; from a security standpoint that is the only way to get the full benefits of Rust’s type safety checks. It is also my opinion that type safety is not a silver bullet; especially in the firmware world where we have to do raw writes to physical memory for MMIO there will always be a ton of unsafe code even if it is all pure Rust.
Thanks for looking into this and for the well-researched answer!
Best Regards, Nate
From: Ayush Singh <ayushdevel1325@...>
Hi Nate
Thanks for the response.
For the std implementation, I do have some idea how to go about implementing it now. The most important thing I realized is that most of the std isn't actually std. For example, std::collection, Vector, Box, Rc, etc are all actually part of alloc and not std. The things that really are part of std include threads, i/o, etc.
I have taken a look at some other people's projects who have tried implementing libstd for other targets and it seems it is possible to write an implementation without libc. It's just very difficult since in most OS besides Linux, the syscall ABI is not stable enough and using libc is just easier and recommended.
As for my earlier patches, Jiewen told me that edkii-rust branch is no longer maintained and that they are now using a different uefi rust implementation for their work.
I did also find that it will be possible to make the std with stable Rust even though if internals use nightly, so that's cool. Some useful projects about writing libstd for new platform that I found are below:
Ayush Singh
On Fri, 8 Apr, 2022, 2:33 am Desimone, Nathaniel L, <nathaniel.l.desimone@...> wrote:
|
|
|