From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by mx.groups.io with SMTP id smtpd.web08.1693.1649872402815828221 for ; Wed, 13 Apr 2022 10:53:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gVOx7Ndk; spf=pass (domain: gmail.com, ip: 209.85.128.178, mailfrom: adachristine18@gmail.com) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-2ebd70a4cf5so31267697b3.3; Wed, 13 Apr 2022 10:53:22 -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; bh=if6Cdgycg3GGxYrDcPAtpvdu6TE1S4VigQMG1fLRD3c=; b=gVOx7NdkQiwOtESReKMlSIMB9olKH6J7iVRtlOsvlBDfWvnP1xn0zAXCS130IBqghz WYMuKkBSvfPzrNOnDdffwzPEWq5H6nOP1v7R0rbHbnvoB1/C/WVkh+cRNry/uNhWUXbr ff2El7190qOAPpD8MyttBMXF/OzeOwWSnRd8sf8OmduE1mSftbwGr+uNb+9r9Ydd8UzV kelqfbom+ii79JrJDeaDH9xsy4EkBcowCdT+gHakRCl09JktzZI+nbslGwAk2NXg94+g zWoJj4t2+PPrjl6wzD6Owj7tx0vgvGxRwGiRy9WoDVs7PUdYtDVDuUwnqfdFFQjHPvsf O/9w== 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; bh=if6Cdgycg3GGxYrDcPAtpvdu6TE1S4VigQMG1fLRD3c=; b=slfzrxyLiRKQDmD2XwoBPqEMftPL7/dgpwuuKZ0ESptIWFsVik4/jrg1DbVJxhGLJB 8EPAnv6oRiZ1zp/L2xxZfvu2/qdV8p5L2xFKge5h5tfJY9AFlvvALQiPGKUtbOqSZW6G 2GRAW7qzYIiDlm/NJmNEkxl/2IqO9H04KoRuf58Fs5YM2Np6RtndhLaMfwOZ8nGOi/Ol vYAZy7JHIcDTzU7ZQGuuJBZ7nzckzV5myACYwKfcYpZ5fLaxSaNnnsqO8AMRDiukps3i 0ByCfa/fXBtC3Uil5CLUXtIqsgmIT/+phTh2BfV/4vDDwcIP6fNl2r16BRTWMkkW7DzO LnSA== X-Gm-Message-State: AOAM532M/y+rdKmz/VYqXCuPzFwqUru8DQSpvU1AEPFoCRy/nVu32K1D S6XyHCPioEjv9kLiniSgnPChAUFAIlRwf119k4o= X-Google-Smtp-Source: ABdhPJzwTNgFICcCFB5DUWtkoo4dY/38Q+5A2n2/m9Jbq34SIXZ1xLN/jZ/FFvFJ5edn3dgC/SDlhfj9ZaiuZeadae8= X-Received: by 2002:a81:c305:0:b0:2eb:9875:76fd with SMTP id r5-20020a81c305000000b002eb987576fdmr37596ywk.317.1649872402082; Wed, 13 Apr 2022 10:53:22 -0700 (PDT) MIME-Version: 1.0 References: <4EC8A9B4-A4BE-45E0-B599-C21552251D54@posteo.de> In-Reply-To: <4EC8A9B4-A4BE-45E0-B599-C21552251D54@posteo.de> From: "Ada Christine" Date: Wed, 13 Apr 2022 17:53:15 +0000 Message-ID: Subject: Re: [edk2-discuss] GSoC Proposal To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: discuss@edk2.groups.io, nathaniel.l.desimone@intel.com, steven.shi@intel.com, devel@edk2.groups.io Content-Type: multipart/alternative; boundary="000000000000736f0505dc8cda9a" --000000000000736f0505dc8cda9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i can submit up to three proposals. I'll give all of this some thought and a little research and start putting at least two proposals together starting Friday. :) On Wed, Apr 13, 2022, 15:15 Marvin H=C3=A4user wrote: > > 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. > > 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. > > 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 > Acidanthera, 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.groups.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. > > 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->MMRAM and BaseMemoryLib would only work > on MMRAM. Also evaluation of how to best avoid pointers in MM communicati= on > buffers would be nice. > > There also is a bunch of other stuff, like working out moving 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 buggy an= d most > platforms mostly abandoned it over various issues), and alternatives to > guarding critical code with SMM (like allowing NVRAM commits only as part > of a reboot). > > I personally find all of those projects very important, but I cannot > promise many people agree. Especially those that impose global changes > (most notably the TE replacement) may be very tedious to submit. Gladly, = I > believe you 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. > > On Wed, Apr 13, 2022, 12:05 Marvin H=C3=A4user wrote= : > > Do you use the =E2=80=9Creply all=E2=80=9D option in your mail client? Lo= oks like my CCs > > have been dropped again. Comments inline. > > > 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 my > > 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 libra= ry > > is changed there's no need to distribute a new version of the whole binar= y, > > just the relevant library module. > > > I really do not like the trend of treating UEFI as a full-fledged OS - it > > 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 us= ed > > applications, you will always get a full snapshot anyhow. Gladly we don= =E2=80=99t > > have auto-update and package management yet. :) > > > > 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. > > > 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 an= app and > > below=E2=80=99s problems apply. > > > If however the whole plan is making the linker as a DXE and including it > > with the firmware, that I'm not quite as sure about. That would necessari= ly > > tie any applications using dynamic linking to TianoCore or any firmware > > distribution that derives from it. > > > I think that was the idea referred to as =E2=80=9Cedk2 core=E2=80=9D by S= teven, but I=E2=80=99d > > like to hear his proposal to be sure. Virtually everyone uses edk2, so th= at > > itself is not the problem, but versioning is. Vendors are slow to update > > their snapshots or have just given up doing that entirely. Distributing i= t > > for external applications like OS loaders would mean this can be leverage= d > > 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. > > > > 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 a= re > > the alternative projects I had thought about. I need to choose fairly soo= n > > 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 project. > > > I have a few more ideas for security stuff, but Nate did not confirm them > > as appropriate yet and I=E2=80=99m not here to drive you away from this s= pecific > > task (or the others). However, I=E2=80=99m still curious and concerned. := ) > > > Best regards, > > Marvin > > > > >=20 > > > --000000000000736f0505dc8cda9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i can submit up to three proposals. I'll give all of = this some thought and a little research and start putting at least two prop= osals together starting Friday. :)

On Wed, Apr 13, 2022, 15:15 Marvin H=C3= =A4user <mhaeuser@posteo.de>= ; wrote:

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 mailing lists before and don't= know how they
work. I'll use my mail client from here = on.

I'm on board with not treating EFI= as an operating system. the more i think
about it the more= it looks like scope creep.

Ag= reed.

I'm not= quite as enthusiastic
about it as i was at first glance.

I'm still keen on doing my gsoc proposa= l for edk, though, and even if this
task and the acpica app= lication are decided to be out of scope unit
testing,

How about fuzz-testing? This is al= so something edk2 needs quite badly. At Acidanthera, we compile edk2 code i= n userspace outside the edk2 build system and fuzz with dummy applications.=

clang integratio= n

Pedro and Vitaly are looking= for someone to finish ASan:=C2=A0https://edk2.gr= oups.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.

how about y= our 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 M= MRAM. Also evaluation of how to best avoid pointers in MM communication buf= fers would be nice.

There also is a bunch of other= stuff, like working out moving a part of CpuDxe into DxeCore to have memor= y protection live immediately, memory protection in PEI, a replacement for = the TE format (it=E2=80=99s buggy and most platforms mostly abandoned it ov= er various issues), and alternatives to guarding critical code with SMM (li= ke allowing NVRAM commits only as part of a reboot).

I personally find all of those projects very important, but I cannot pro= mise many people agree. Especially those that impose global changes (most n= otably the TE replacement) may be very tedious to submit. Gladly, I believe= you can submit multiple proposals (?)

Best regard= s,
Marvin

I'm not very knowledgeable about
trusted platform o= r secure boot but I'm willing to learn whatever is
nece= ssary to get something spun up for my proposal.

= On Wed, Apr 13, 2022, 12:05 Marvin H=C3=A4user <mhaeuser@posteo.de= > wrote:

= Do you use the =E2=80=9Creply all=E2=80=9D option in your mail client? Look= s like my CCs
have b= een dropped again. Comments inline.

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

Its similarity to my own latest experiment is the key= to what grabbed my
attention. I have no particular use case in mind for it, but I= see its
potential f= or anybody developing larger applications in that when a library
=
is changed there's no need= to distribute a new version of the whole binary,
just the relevant library module.
<= /blockquote>

I really do not like the trend of treating UEFI as= a full-fledged OS - it
is not. The most used UEFI applications, OS loaders, are really not tha= t
huge and are distr= ibuted as part of the OS image anyway. Even for less used
applications, you will always get a f= ull snapshot anyhow. Gladly we don=E2=80=99t
have auto-update and package management yet. :)


<= span>I slept on it and it occurred to me that the whole thing could operate=
simila= rly to the shell protocol in that the linker/loader is itself an
=
application that does a LoadIm= age() on the application needing dynamic
linking facilities.

That would mean the linker itself is shipped with every application that<= /span>
requires it? Otherwi= se it doesn=E2=80=99t make much sense for it to be an app and
below=E2=80=99s problems apply.

If however the= whole plan is making the linker as a DXE and including it
with the firmware, that= I'm not quite as sure about. That would necessarily
tie any applications using dynamic lin= king 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. Virtually everyone us= es edk2, so that
its= elf is not the problem, but versioning is. Vendors are slow to update
their snapshots or have j= ust given up doing that entirely. Distributing it
for external applications like OS loaders wou= ld mean this can be leveraged
probably no earlier than 10 years from now. And for in-firmware t= hings, I
have a hard= time thinking about a use-case that outweighs the drawbacks.


To shi= ft the topic slightly back to GSoC, however, I'm willing to work=
on other item= s on the task list. Unit testing and an ACPICA application are
the alternative projects I had t= hought about. I need to choose fairly soon
as the proposal deadline is next Tuesday. I know a t= iny bit about porting
ACPICA as I also have plans to incorporate it into my own project.=

I have a few more ideas for security stuff, b= ut 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 concerned. :)

<= blockquote type=3D"cite">Best regards,
Marvin






--000000000000736f0505dc8cda9a--