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 <nathaniel.l.desim...@intel.com> wrote: > 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 > super valuable because LZMA compression is becoming ineffective because > compiler optimization is getting so good that the patterns for a library > across binaries don’t match very well anymore. For XIP PEI code… 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 <pedro.falc...@gmail.com> > Sent: Wednesday, April 13, 2022 11:43 AM > To: edk2-devel-groups-io <devel@edk2.groups.io>; Marvin Häuser < > mhaeu...@posteo.de> > Cc: disc...@edk2.groups.io; adachristin...@gmail.com; Desimone, Nathaniel > L <nathaniel.l.desim...@intel.com>; Shi, Steven <steven....@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 > complete operating system, but to try to eliminate the static linking that > 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 .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äuser <mhaeu...@posteo.de<mailto: > mhaeu...@posteo.de>> wrote: > > On 13. Apr 2022, at 16:38, Ada Christine <adachristin...@gmail.com<mailto: > adachristin...@gmail.com>> wrote: > i was replying via the groups.io<http://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. > > 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 this > 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 communication > 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’s buggy and 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äuser <mhaeu...@posteo.de<mailto: > mhaeu...@posteo.de>> wrote: > > > Do you use the “reply all” option in your mail client? Looks like my CCs > have been dropped again. Comments inline. > > On 13. Apr 2022, at 12:54, Ada Christine <adachristin...@gmail.com<mailto: > adachristin...@gmail.com>> > wrote: > Hi, 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 binary, > 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’t > 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’t make much sense for it to be an app and > below’s 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 linking to TianoCore or any firmware > distribution that derives from it. > > I think that was the idea referred to as “edk2 core” by Steven, but I’d > 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 > for external applications like OS loaders would mean this can be leveraged > 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 are > the alternative projects 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 project. > > I have a few more ideas for security stuff, but Nate did not confirm them > as appropriate yet and I’m not here to drive you away from this specific > task (or the others). However, I’m still curious and concerned. :) > > Best regards, > Marvin > > > > > > > > > -- > Pedro Falcato > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88895): https://edk2.groups.io/g/devel/message/88895 Mute This Topic: https://groups.io/mt/90435699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
