From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mx.groups.io with SMTP id smtpd.web09.21073.1650132647608848202 for ; Sat, 16 Apr 2022 11:10:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Gq24VeIP; spf=pass (domain: gmail.com, ip: 209.85.167.54, mailfrom: ayushdevel1325@gmail.com) Received: by mail-lf1-f54.google.com with SMTP id g19so4687052lfv.2 for ; Sat, 16 Apr 2022 11:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mxMS9MaFglk0szxdCqFTvGJ+Z2wVa/+Gx0yV1ULXXHE=; b=Gq24VeIPOFn1Bvr8KOT6QMcuL0wxq8Ui9Gg8B0IAPKsX2v4tnD7H03S1d1x7GGBeQk AUmYkcgynGPPDmqd+k/KWYSTQl7xg/9b6o936yHzn/LbQvIGTEb99oGV6rwH3QRbhgKi 2um0mjE6BWcSnPBqPl9iyQwbKJFvmj63Bvx8mDzoqDM1AK/9RULLwXJtyREV98c9/8wm tBrcn/ifRRIMRJ//bpUBByuRWQy3g70kH9K938taeACeMheL0HTaf+eOwokBZaR3TJ5Q tQrmvHk34gOprtNxoXliY8kK1vz7zF7KLrknOTGteX1SE00z3dyPKHUgUkhd5Hm1fRIv i61w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mxMS9MaFglk0szxdCqFTvGJ+Z2wVa/+Gx0yV1ULXXHE=; b=btvsZVBorBfsbsEkGi5+/mg3vE461LWZ/CJk8vQzfHjs1NndavM6gkIC1AshuN6Jy5 GtbybQL20otDIPDo+p+iUc9/6BC5vhJvRuqsao+ELC2T0zRcn/PWwWekK05Tc0EnI0ww aQY0QLqVulA4liU9A7SZZqH/dPN+XuvISiY02fxFWTZdI7fT/JteECygBuH7nVRRGoiN J/BDfeBWtwZ6Wqn6eOxdQwRtkxMPB0lQGi4W3ogIH/81UJFuBEZzqZU6Wg8mcogJXFZQ Uc1Z6VKTA+M1XPiFq1D5aT8zqZu0DFOlTpD4dUeB5WgFkgEOELZyBVPLy80zV7GjushN 18UA== X-Gm-Message-State: AOAM531ahD5vGkEBQGK/ej6a1vmtrmOEGQlAPV/7mtUqgQ41hUwFGiOn s6EC90waCJiL6GKRFcL8KlIotFsIBPjaubodaxA= X-Google-Smtp-Source: ABdhPJwZeSripX7+F2eFo8Dwpq5g/q7ncnteMVUpsOgi6qCUOUkrH/DdoY9O8G4rLebawBQA8bW4XBn55pKeUSyY500= X-Received: by 2002:a05:6512:b1e:b0:44a:9b62:3201 with SMTP id w30-20020a0565120b1e00b0044a9b623201mr3185661lfu.42.1650132645848; Sat, 16 Apr 2022 11:10:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ayush Singh" Date: Sat, 16 Apr 2022 23:40:34 +0530 Message-ID: Subject: Re: [edk2-devel] Applying for GSoC 2022: Add Rust Support to EDK II To: "Desimone, Nathaniel L" Cc: edk2-devel-groups-io , Bret Barkelew , =?UTF-8?Q?Marvin_H=C3=A4user?= , "Yao, Jiewen" , Pedro Falcato Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > Hi Ayush, > > > > Very interesting and intellectually stimulating, thank you! It makes sens= e 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 implement= s the syscall interface *is* libc and any library that provides a syscall w= rapper 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 functi= on 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 funct= ion pointer calls out to the UEFI services for memory allocation and whatno= t. 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 su= ch it would probably make sense to build a Rust implementation of a heap th= at allocates and frees pages as necessary so that it will be possible to us= e std on both PEI and DXE. > > > > With regard to Jiewen=E2=80=99s rust-firmware project, my personal opinio= n is that his approach is more long term and aspirational. Given that EDK I= I is now deployed on ~4 billion devices around the world, I don=E2=80=99t t= hink 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 opini= on would be to allow some mix of C and Rust code to co-exist and if firmwar= e implementations evolve towards a greater mix of Rust code over time than = something like Jiewen=E2=80=99s proposal could become feasible. But in the = short term my opinion is slowly introducing Rust over time is the only feas= ible option. I understand Jiewen=E2=80=99s reasons for preferring a 100% Ru= st; from a security standpoint that is the only way to get the full benefit= s of Rust=E2=80=99s type safety checks. It is also my opinion that type saf= ety 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 > Sent: Friday, April 8, 2022 5:41 AM > To: Desimone, Nathaniel L > Cc: edk2-devel-groups-io ; Bret Barkelew ; Marvin H=C3=A4user ; 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 implement= ing 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 implem= enting libstd for other targets and it seems it is possible to write an imp= lementation 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 lo= nger maintained and that they are now using a different uefi rust implement= ation 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, 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 R= ust 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 fo= r 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 I= I, 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 b= e figuring out how to integrate the vast array of libraries that EDK II pro= vides into a coherent and clean Rust binding. The one aspect of this projec= t 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 as= sumes 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 in= terested 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 On Behalf Of Ayush Sing= h > Sent: Monday, April 4, 2022 10:18 AM > To: devel@edk2.groups.io > Cc: Bret.Barkelew@microsoft.com; Desimone, Nathaniel L ; 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 inter= ested in applying for adding Rust support to EDK2. I have already introduce= d myself to the mailing list earlier > (https://edk2.groups.io/g/devel/message/87637) and have even submitted so= me 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 so= mething before submitting an application. So should I directly start by sub= mitting a proposal through the GSoC application portal? Or is there someone= I should contact first? > > Ayush Singh > > >=20 >