Re: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II

["Ayush Singh" <ayushdevel1325@gmail.com>]

Thanks,

I have updated my Proposal based on the discussion on the mailing
list, so feel free to give feedback on that.

As far as my views go, I agree that it's not realistic to convert all
edk2 to Rust. I think of this project to be about making Rust an
option to do firmware development in, and stand alongside C. Maybe
Rust will replace all the C someday, but I would be more interested in
writing new parts in Rust rather than rewriting something that already
works perfectly fine.

And yes, it is pretty difficult to remove unsafe from firmware
development, but I think it might actually be possible to write UEFI
applications without unsafe, although that might just be me being
optimistic. Also, unsafe Rust is at worst as unsafe as normal C, so it
still should be a slight improvement. The best thing would be when we
can use collections and stuff in firmware development. That would
definitely be pretty cool.

Ayush


On Thu, Apr 14, 2022 at 6:30 AM Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com> wrote:
>
> 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@gmail.com>
> Sent: Friday, April 8, 2022 5:41 AM
> To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Marvin Häuser <mhaeuser@posteo.de>; Yao, Jiewen <jiewen.yao@intel.com>
> Subject: Re: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II
>
>
>
> 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:
>
> - https://github.com/betrusted-io/rust/tree/1.54.0.5
>
> - https://github.com/japaric/steed
>
>
>
> Ayush Singh
>
>
>
> On Fri, 8 Apr, 2022, 2:33 am Desimone, Nathaniel L, <nathaniel.l.desimone@intel.com> wrote:
>
> Hi Ayush,
>
> Great to meet you and welcome to the TianoCore project! Great to hear you are interested! Apologize for the tardiness in my response. Implementing Rust support sounds like a wonderful project and one that would really help advance the state of the art for UEFI firmware development! I am looking for someone with Rust experience that can help mentor this project. My usage of Rust at time of writing has not advanced very far beyond "Hello World." While I can give a great deal of knowledge and background on UEFI and EDK II, my ability to recommend how that be applied to a Rust binding is limited. However, I do know enough to suspect the vast majority of the work will be figuring out how to integrate the vast array of libraries that EDK II provides into a coherent and clean Rust binding. The one aspect of this project that I think will be interesting is figuring out is what to do about std:: in Rust. From what I have seen of the functionality there more or less assumes the existence of a libc implementation for the platform, which is not necessarily true for DXE and is absolutely not true for PEI. I would be interested in hearing your thought on how to handle that elegantly.
>
> I'm sorry that your patches haven't gotten much attention thus far. Once I find mentor(s) for the Rust project I'll make sure they pick those up and take a look at the work you have done thus far.
>
> Hope this helps and welcome to the project!
>
> With Best Regards,
> Nate
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ayush Singh
> Sent: Monday, April 4, 2022 10:18 AM
> To: devel@edk2.groups.io
> Cc: Bret.Barkelew@microsoft.com; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; mhaeuser@posteo.de
> Subject: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II
>
> Hello everyone, I am a 2nd-year University Student from India. I am interested in applying for adding Rust support to EDK2. I have already introduced myself to the mailing list earlier
> (https://edk2.groups.io/g/devel/message/87637) and have even submitted some patches for the edkii-rust branch in edk2-staging (which were not merged since that branch seems to be abandoned now).
> - https://edk2.groups.io/g/devel/message/87753
> - https://edk2.groups.io/g/devel/message/87754
> - https://edk2.groups.io/g/devel/message/87755
> - https://edk2.groups.io/g/devel/message/87756
>
> Anyway, since no mentor has been listed for this project, I was wondering who should I discuss the proposal with? Normally, I think one is supposed to discuss the proposal details with a mentor in form of a google doc or something before submitting an application. So should I directly start by submitting a proposal through the GSoC application portal? Or is there someone I should contact first?
>
> Ayush Singh
>
>
> 
>