From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) by mx.groups.io with SMTP id smtpd.web08.6741.1649899818010833750 for ; Wed, 13 Apr 2022 18:30:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZcHPFCtl; spf=pass (domain: gmail.com, ip: 209.85.128.171, mailfrom: adachristine18@gmail.com) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-2edbd522c21so40555517b3.13; Wed, 13 Apr 2022 18:30:17 -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=7+P4qYyJNAbzNgrcLAYd4UVj8fWGtERYTQWLi1oU67c=; b=ZcHPFCtlT0nqFQP0wnfteFsI8PxHy2kEfcSKefHf5y6ScEG3vNIhHrOm8sE2ktipyl 9Dpo5hWZZ0/cjPakiNkbg21W/EPo9NeXKJftsG0/2VoZfBjoXPIB9nw3LdSe5v/cXj9e TBqwz/rxBz30tvlzgQKYKC/3JhMcpjPCyXHVCD8KkvHq2L1ltSJYRhpjWBdrq6iURnLy mrfca6Cvz+6c9Olj9+ldTrsxUFJZRR/xn+AxJwTa1GqoEOBW3ymoRJTJ2lcLkBLFNW+i oCHJwaxQfHuqaStPu7dOoyRgfBYsJv4WAqcSdhws07RJwRPVWn2af7G3MlWZTj2rrGhE /iiw== 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=7+P4qYyJNAbzNgrcLAYd4UVj8fWGtERYTQWLi1oU67c=; b=zjyf46FRIfpoMdCEs82A44QZT4UQZAXy1Y1mZgybUIVhPPVifSFnFyZbTws8ZuRsuG RaZIZctQQ4tgnhzwrvw2SnheCnt9xqIvm6XaaVjAz2UoCy+N8XvH08ZSDtBbut+5wD+U NS3xKJDrvPCr8TH961q2VPsQhQwWm8eGF8JlL0/pO9a32s+WWomYHmJJyN9j7toELug4 Envc65VozgxH8Lo93Wt/oEveUxsfjBNJhvMFZlqz1fNdnffveMhuv+Yn20uLV82hnkxu /h2jZAAYA7482I94T1pSvWRapenE7B57piELeE8XQNWXU1P2p5s7lLPYU1KH6A40AhMz kabg== X-Gm-Message-State: AOAM531gpm5+DQyhwWcPmVqXagRqD0JB0Qn1eiY6Mpojw/i3RROiONRo vOzO+ureXs038Vkuwt0GNVgy26Efg4IwnjMoaKNQakNCYiLYDw== X-Google-Smtp-Source: ABdhPJwmXnXuIjDmvNBX9A6Lhjm207WSvNxHHJ2M6UOPQ4xh2OAhuq5Wd+a0BYk71rGecOZkVr6rZKRplblgZ74NGaY= X-Received: by 2002:a81:b044:0:b0:2d6:bd1f:5d8b with SMTP id x4-20020a81b044000000b002d6bd1f5d8bmr261115ywk.27.1649899817139; Wed, 13 Apr 2022 18:30:17 -0700 (PDT) MIME-Version: 1.0 References: <4EC8A9B4-A4BE-45E0-B599-C21552251D54@posteo.de> In-Reply-To: From: "Ada Christine" Date: Thu, 14 Apr 2022 01:30:10 +0000 Message-ID: Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal To: discuss@edk2.groups.io, nathaniel.l.desimone@intel.com Cc: Pedro Falcato , edk2-devel-groups-io , =?UTF-8?Q?Marvin_H=C3=A4user?= , "Shi, Steven" Content-Type: multipart/alternative; boundary="00000000000084025205dc933c0a" --00000000000084025205dc933c0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i understand now, thank you for clarifying! I'm on board and I'll get to work on a more complete plan as soon as possible. i can probably have a draft proposal done by EOD Saturday. i know it's a holiday weekend, so i don't expect anybody to hop to (pun intended) to critique :) On Wed, Apr 13, 2022, 22:57 Nate DeSimone wrote: > Hi All, > > Pedro is 100% correct. The primary use case and the reason I added this i= s > to remove library duplication across all the .efi files. This is actually > super valuable because LZMA compression is becoming ineffective because > compiler optimization is getting so good that the patterns for a library > across binaries don=E2=80=99t match very well anymore. For XIP PEI code= =E2=80=A6 it will > really help and would be very timely since the transition of PEI from > 32-bit to 64-bit is going to increase the size of PEI by ~20%. > > Thanks, > Nate > > From: Pedro Falcato > Sent: Wednesday, April 13, 2022 11:43 AM > To: edk2-devel-groups-io ; Marvin H=C3=A4user < > mhaeuser@posteo.de> > Cc: discuss@edk2.groups.io; adachristine18@gmail.com; Desimone, Nathaniel > L ; Shi, Steven > Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal > > Hi Marvin, Ada, > > Some comments: > > I don't think the purpose of the dynamic linker is to treat EFI as a > complete operating system, but to try to eliminate the static linking tha= t > may be needlessly duplicating > code that could instead be put in a single dynamic library. For instance, > MdePkg and MdeModulePkg are linked into a *lot* of .efi, instead of being > just a library. It'd be nice to see some > numbers on this (something like Google's bloaty could be run on every .ef= i > file, in order to understand how much file space we would actually save). > > Other comments inline. > > On Wed, Apr 13, 2022 at 4:15 PM 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 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. > > Note: fuzzing is also part of the LLVM instrumentation suite (see > https://llvm.org/docs/LibFuzzer.html) and is something I could happily > mentor. > 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. > > Is Vitaly going to be a mentor? I was assuming it was going to be me and > some other, more senior, mentor (possibly Steven Shi, which I included in > the task). > Anyway, re: ASAN, if the project includes ASAN, UBSAN and possibly some > other sanitizer it's quite possible that it could be considered a large > project (which means more hours but a larger stipend too). Fuzzing + > coverage could > be very nice additions to this project idea. > Also, is stress-testing a decent idea? > > > 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 mhaeuser@posteo.de>> 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 adachristine18@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 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 > > > > > > > > > -- > Pedro Falcato > > >=20 > > > --00000000000084025205dc933c0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i understand now, thank you for clarifying! I'm on bo= ard and I'll get to work on a more complete plan as soon as possible. i= can probably have a draft proposal done by EOD Saturday. i know it's a= holiday weekend, so i don't expect anybody to hop to (pun intended) to= critique :)

On Wed, Apr 13, 2022, 22:57 Nate DeSimone <nathaniel.l.desimone@intel.com> wro= te:
Hi All,

Pedro is 100% correct. The primary use case and the reason I added this is = to remove library duplication across all the .efi files. This is actually s= uper valuable because LZMA compression is becoming ineffective because comp= iler optimization is getting so good that the patterns for a library across= binaries don=E2=80=99t match very well anymore. For XIP PEI code=E2=80=A6 = it will really help and would be very timely since the transition of PEI fr= om 32-bit to 64-bit is going to increase the size of PEI by ~20%.

Thanks,
Nate

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Wednesday, April 13, 2022 11:43 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Marvin H=C3=A4= user <mhaeuser@posteo.de>
Cc: discuss@edk2.groups.io; adachristine18@gmail.com; Des= imone, Nathaniel L <nathaniel.l.desimone@intel.com>; = Shi, Steven <steven.shi@intel.com>
Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal

Hi Marvin, Ada,

Some comments:

I don't think the purpose of the dynamic linker is to treat EFI as a co= mplete operating system, but to try to eliminate the static linking that ma= y be needlessly duplicating
code that could instead be put in a single dynamic library. For instance, M= dePkg and MdeModulePkg are linked into a *lot* of .efi, instead of being ju= st a library. It'd be nice to see some
numbers on this (something like Google's bloaty could be run on every .= efi file, in order to understand how much file space we would actually save= ).

Other comments inline.

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

On 13. Apr 2022, at 16:38, Ada Christine <adachristine18@gmail.com= <mailto:adachristine18@gmail.com>> wrote:
=EF=BB=BFi was replying via the groups.io<http://groups.io&g= t; 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 t= hink
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 t= his
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.

Note: fuzzing is also part of the LLVM instrumentation suite (see https://llvm.org/docs/LibFuzzer.html) and is something I= could happily mentor.
clang integration

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

Is Vitaly going to be a mentor? I was assuming it was going to be me and so= me other, more senior, mentor (possibly Steven Shi, which I included in the= task).
Anyway, re: ASAN, if the project includes ASAN, UBSAN and possibly some oth= er sanitizer it's quite possible that it could be considered a large pr= oject (which means more hours but a larger stipend too). Fuzzing + coverage= could
be very nice additions to this project idea.
Also, is stress-testing a decent idea?


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. 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 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.

On Wed, Apr 13, 2022, 12:05 Marvin H=C3=A4user <mhaeuser@posteo.de&l= t;mailto: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 been dropped again. Comments inline.

On 13. Apr 2022, at 12:54, Ada Christine <adachristine18@gmail.com= <mailto:adachristine18@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 for anybody developing larger applications in that when a library=
is changed there's no need to distribute a new version of the whole bin= ary,
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 used=
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 a= pp 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 necessa= rily
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 Ste= ven, but I=E2=80=99d
like to hear his proposal to be sure. Virtually everyone uses edk2, so that=
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<= br> for external applications like OS loaders would mean this can be leveraged<= br> 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<= br> 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 soon<= br> 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 spe= cific
task (or the others). However, I=E2=80=99m still curious and concerned. :)<= br>
Best regards,
Marvin








--
Pedro Falcato





--00000000000084025205dc933c0a--