From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web09.7545.1649862921173399765 for ; Wed, 13 Apr 2022 08:15:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=mpvrB7I3; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9C81E240109 for ; Wed, 13 Apr 2022 17:15:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1649862919; bh=L4FenITPwanTwL0VlkOt367SGYaR4NbwwFZtyY0RWyA=; h=Subject:From:Cc:Date:To:From; b=mpvrB7I3gtRNCHK6QVPul9j8y8vMC04I+85qQWtO9Osm2vi8kkoun3oTPts/GsttX UDxU+AccZL7TJWwN5BFg1aS+ziadS5TeSKeMd6wCHORox9VJwyN6W+i04PBuVtj580 bOjoogLY+CkO4JIfv5SX33IoYlsanOmcdVG3GNhy+ZZTox7MJwWt0/qBIbIRJdYqVX cGYBNDy5931SdMYVD6QF27sj6ZhzGJFIxkBIdDSxQi0bneiU7zJHwvr7pqM5eEeoxH edMEHPte0NaqKUkriFN8/W/WIT0fVZDTewoqxELctvn6VxZLeoeq7lFQu4llmGwvRQ g33Ia6Im3I85A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4KdmP23tdqz9rxP; Wed, 13 Apr 2022 17:15:18 +0200 (CEST) Mime-Version: 1.0 (1.0) Subject: Re: [edk2-discuss] GSoC Proposal From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Cc: nathaniel.l.desimone@intel.com, steven.shi@intel.com, devel@edk2.groups.io Date: Wed, 13 Apr 2022 15:15:17 +0000 Message-Id: <4EC8A9B4-A4BE-45E0-B599-C21552251D54@posteo.de> References: To: discuss@edk2.groups.io, adachristine18@gmail.com Content-Type: multipart/alternative; boundary=Apple-Mail-64AE5292-A84C-4E5A-BAEB-C0D708360F5D Content-Transfer-Encoding: 7bit --Apple-Mail-64AE5292-A84C-4E5A-BAEB-C0D708360F5D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 13. Apr 2022, at 16:38, Ada Christine wrote= : > =EF=BB=BFi was replying via the groups.io web interface, I'm guessing tha= t messed up > the thread? i haven't used mailing lists before and don't know how they > work. I'll use my mail client from here on. >=20 > I'm on board with not treating EFI as an operating system. the more i thi= nk > about it the more it looks like scope creep. Agreed. > I'm not quite as enthusiastic > about it as i was at first glance. >=20 > I'm still keen on doing my gsoc proposal for edk, though, and even if thi= s > task and the acpica application are decided to be out of scope unit > testing, How about fuzz-testing? This is also something edk2 needs quite badly. At A= cidanthera, we compile edk2 code in userspace outside the edk2 build system= and fuzz with dummy applications. > clang integration Pedro and Vitaly are looking for someone to finish ASan: https://edk2.group= s.io/g/devel/topic/90010978#87991 There are working UBSan concepts, but they also need to be mainlined. > and source-level debugging are all relevant to > my interests. >=20 > how about your ideas for security stuff? I want the entirety of MM to leverage SmmMemLib and to support SMAP. SmmMem= Lib would then handle UEFI->MMRAM and BaseMemoryLib would only work on MMRA= M. Also evaluation of how to best avoid pointers in MM communication buffer= s would be nice. There also is a bunch of other stuff, like working out moving a part of Cpu= Dxe into DxeCore to have memory protection live immediately, memory protect= ion in PEI, a replacement for the TE format (it=E2=80=99s buggy and most pl= atforms mostly abandoned it over various issues), and alternatives to guard= ing critical code with SMM (like allowing NVRAM commits only as part of a r= eboot). I personally find all of those projects very important, but I cannot promis= e many people agree. Especially those that impose global changes (most nota= bly the TE replacement) may be very tedious to submit. Gladly, I believe yo= u can submit multiple proposals (?) Best regards, Marvin > I'm not very knowledgeable about > trusted platform or secure boot but I'm willing to learn whatever is > necessary to get something spun up for my proposal. >=20 > On Wed, Apr 13, 2022, 12:05 Marvin H=C3=A4user wrote= : >=20 >> Do you use the =E2=80=9Creply all=E2=80=9D option in your mail client? L= ooks like my CCs >> have been dropped again. Comments inline. >>=20 >>> On 13. Apr 2022, at 12:54, Ada Christine >> wrote: >>> =EF=BB=BFHi, Marvin >>> Its similarity to my own latest experiment is the key to what grabbed m= y >> attention. I have no particular use case in mind for it, but I see its >> potential for anybody developing larger applications in that when a libr= ary >> is changed there's no need to distribute a new version of the whole bina= ry, >> just the relevant library module. >>=20 >> I really do not like the trend of treating UEFI as a full-fledged OS - i= t >> is not. The most used UEFI applications, OS loaders, are really not that >> huge and are distributed as part of the OS image anyway. Even for less u= sed >> applications, you will always get a full snapshot anyhow. Gladly we don= =E2=80=99t >> have auto-update and package management yet. :) >>=20 >>> I slept on it and it occurred to me that the whole thing could operate >> similarly to the shell protocol in that the linker/loader is itself an >> application that does a LoadImage() on the application needing dynamic >> linking facilities. >>=20 >> That would mean the linker itself is shipped with every application that >> requires it? Otherwise it doesn=E2=80=99t make much sense for it to be a= n app and >> below=E2=80=99s problems apply. >>=20 >>> If however the whole plan is making the linker as a DXE and including i= t >> with the firmware, that I'm not quite as sure about. That would necessar= ily >> tie any applications using dynamic linking to TianoCore or any firmware >> distribution that derives from it. >>=20 >> I think that was the idea referred to as =E2=80=9Cedk2 core=E2=80=9D by = Steven, but I=E2=80=99d >> like to hear his proposal to be sure. Virtually everyone uses edk2, so t= hat >> itself is not the problem, but versioning is. Vendors are slow to update >> their snapshots or have just given up doing that entirely. Distributing = it >> for external applications like OS loaders would mean this can be leverag= ed >> probably no earlier than 10 years from now. And for in-firmware things, = I >> have a hard time thinking about a use-case that outweighs the drawbacks. >>=20 >>> To shift the topic slightly back to GSoC, however, I'm willing to work >> on other items on the task list. Unit testing and an ACPICA application = are >> the alternative projects I had thought about. I need to choose fairly so= on >> as the proposal deadline is next Tuesday. I know a tiny bit about portin= g >> ACPICA as I also have plans to incorporate it into my own project. >>=20 >> I have a few more ideas for security stuff, but Nate did not confirm the= m >> as appropriate yet and I=E2=80=99m not here to drive you away from this = specific >> task (or the others). However, I=E2=80=99m still curious and concerned. = :) >>=20 >> Best regards, >> Marvin >=20 >=20 >=20 --Apple-Mail-64AE5292-A84C-4E5A-BAEB-C0D708360F5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 13. Apr 2022, at 16:38, Ada Christine <adachristine18@gmail= .com> wrote:

=EF=BB=BFi was replying via the groups.io web interface, I'= m guessing that messed up
the thread? i haven't used mailin= g lists before and don't know how they
work. I'll use my ma= il client from here on.

I'm on board with = not treating EFI as an operating system. the more i think
a= bout it the more it looks like scope creep.
<= br>
Agreed.

<= span>I'm not quite as enthusiastic
about it as i was at fir= st glance.

I'm still keen on doing my gsoc= proposal for edk, though, and even if this
task and the ac= pica application are decided to be out of scope unit
testin= g,

How about fuzz-testing? Th= is is also something edk2 needs quite badly. At Acidanthera, we compile edk= 2 code in userspace outside the edk2 build system and fuzz with dummy appli= cations.

clang in= tegration

Pedro and Vitaly are= looking for someone to finish ASan: https://edk2.groups.io/g/devel/topic/9001097= 8#87991
There are working UBSan concepts, but they also need = to be mainlined.

= and source-level debugging are all relevant to
my interests= .

how about your ideas for security stuff?=

I want the entirety of MM to = leverage SmmMemLib and to support SMAP. SmmMemLib would then handle UEFI-&g= t;MMRAM and BaseMemoryLib would only work on MMRAM. Also evaluation of how = to best avoid pointers in MM communication buffers would be nice.

There also is a bunch of other stuff, like working out movi= ng a part of CpuDxe into DxeCore to have memory protection live immediately= , memory protection in PEI, a replacement for the TE format (it=E2=80=99s b= uggy and most platforms mostly abandoned it over various issues), and alter= natives to guarding critical code with SMM (like allowing NVRAM commits onl= y as part of a reboot).

I personally find all of t= hose projects very important, but I cannot promise many people agree. Espec= ially those that impose global changes (most notably the TE replacement) ma= y be very tedious to submit. Gladly, I believe you can submit multiple prop= osals (?)

Best regards,
Marvin

=
I'm not very knowledgeabl= e about
trusted platform or secure boot but I'm willing to = learn whatever is
necessary to get something spun up for my= proposal.

On Wed, Apr 13, 2022, 12:05 Mar= vin H=C3=A4user <mhaeuser@posteo.de> wrote:
Do you use the =E2=80=9Creply all=E2=80= =9D option in your mail client? Looks like my CCs
have been dropped again. Comments inline.

On 13. Apr 2022,= at 12:54, Ada Christine <adachristine18@gmail.com>
wrote:
=EF=BB=BFHi= , Marvin

Its similarity to my own la= test experiment is the key to what grabbed my
attention. I have no particular use = case in mind for it, but I see its
potential for anybody developing larger applications in tha= t when a library
is = changed there's no need to distribute a new version of the whole binary,
just the relevant libr= ary module.
<= br>
I really do not like the tr= end of treating UEFI as a full-fledged OS - it
is not. The most used UEFI applications, OS load= ers, are really not that
<= span>huge and are distributed as part of the OS image anyway. Even for less= used
applications, = you will always get a full snapshot anyhow. Gladly we don=E2=80=99t<= br>
have auto-update and packag= e management yet. :)


I slept on it and it occurred to me that the wh= ole thing could operate
similarly to the shell protocol in that the linker/loader = is itself an
applica= tion that does a LoadImage() on the application needing dynamic
<= /blockquote>
linking facilities.
<= /blockquote>

That would mean the linker itself is shipped with = every application that
requires it? Otherwise it doesn=E2=80=99t make much sense for it to be a= n app and
below=E2= =80=99s problems apply.

If however the whole plan is making the linker as a DXE and incl= uding it
with the firmware, that I'm not quite as sure about. That would necessari= ly
tie any applicati= ons using dynamic linking to TianoCore or any firmware
distribution that derives from it.

<= blockquote type=3D"cite">I think that was the idea referred to as =E2= =80=9Cedk2 core=E2=80=9D by Steven, but I=E2=80=99d
=
like to hear his proposal to be sure. Virtu= ally everyone uses edk2, so that
itself is not the problem, but versioning is. Vendors are slow= to update
their sna= pshots or have just given up doing that entirely. Distributing it
for external applications lik= e OS loaders would mean this can be leveraged
probably no earlier than 10 years from now. And f= or in-firmware things, I
<= span>have a hard time thinking about a use-case that outweighs the drawback= s.

To shift the topic slightly back to GSoC, however, I'm willing to= work
o= n other items on the task list. Unit testing and an ACPICA application are<= /span>
the alternative proj= ects I had thought about. I need to choose fairly soon
as the proposal deadline is next Tuesday= . I know a tiny bit about porting
ACPICA as I also have plans to incorporate it into my own p= roject.

<= /blockquote>
I have a few more ideas for sec= urity stuff, but Nate did not confirm them
as appropriate yet and I=E2=80=99m not here to drive= you away from this specific
task (or the others). However, I=E2=80=99m still curious and conce= rned. :)

=
Best regards,
Marvin






--Apple-Mail-64AE5292-A84C-4E5A-BAEB-C0D708360F5D--