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äuser <mhaeu...@posteo.de> wrote: > > On 13. Apr 2022, at 16:38, Ada Christine <adachristin...@gmail.com> wrote: > > i 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. > > > 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. > > 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 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> 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> > > 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 > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#88879): https://edk2.groups.io/g/devel/message/88879 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] -=-=-=-=-=-=-=-=-=-=-=-
