Oh I see what was meant - ignore me! I do think it would be good to have more discussions on edk2-discuss though :) -- Rebecca Cran

Just a minor correction - it's edk2-discuss (discuss@edk2.groups.io) that was cc'd but that's pretty dead. edk2-devel (devel@edk2.groups.io) is much more active! -- Rebecca Cran

One solution is to add `-fno-stack-protector` to `GCC5_AARCH64_CC_FLAGS`. -- Oliver

Andrew pointed out that PEI was originally intended for memory init, and DXE for the rest. One nice aspect of that is that there's a simple, architected, consolidated handoff of state between them:

I've submitted an updated version of my proposal document. There's a little more detail and I've shifted from using the term "dynamic linking" to "code sharing" to reflect the fact that the question

Hi Marvin,

Hey Isaac, Thanks for your input! :) Looking at the amount of things that are duplicated from DXE to PEI (MP, variable services, PCD, GOP, ...), this sounds like all the more reason to me to have

In practice, it feels like we have evolved far beyond original PEI scope for natural and good reasons. Initially, it was very resource constrained. 8KB CAR for data only. That is no longer a real

Hey Brian, Personally, I don't think this topic can get enough attention. Thanks! :) My suggestion to use a private function array would indeed require shims, however this would be the "better than

Nate, Andrew, Marvin, Pedro, Ada, et al, This is a great discussion. I've been debating where to weigh in... I agree that some sort of library sharing to reduce image size would be very helpful.

I mean, did you plan to deploy ASan in production? I'm not sure a full implementation is performant or compatible with space constraints. Being a debug feature, I'm surprised this is a reason for

Exactly. Lacking of doc from different compilers is very painful. The Asan or UBsan support is just a hack -

Historically the challenge we had w/ upstreaming some features was if the compiler intrinsic for which a particular feature was dependent didn't have public documentation or wasn't supported by all of

Hey Vincent, In fact I haven't, thanks a lot! Are there any known blockers for these outside development resources? Except for C++, they are things we'd want asap downstream. I guess rather than

Fyi There is a running list of some edk2 defense-in-depth work at https://github.com/jyao1/SecurityEx/blob/master/Summary.md, too, including ASLR, if you haven't already seen that material

CC Mike (proposal review as per announcement mail) Hey Ada, I can neither decide on nor even view your proposal (I think that's up to Nate and Mike?), but I had a brief conversation with Vitaly

Hi Everybody I've read all the discussion here and condensed my plan into a short project proposal. It's a little short and light on detail at the moment because I'm pressed for time for other

Hi Andrew, One of the big reasons a lot of code that should have been written in DXE ended up in PEI is unfortunately due to the FSP and its inability to support DXE code.

It’s not about the fact that stages of rising complexity exist (SEC for example is nice), but more so that the PEI and DXE dispatchers share quite a bunch of code. PEI has more of a “DXE light”

I’d also point out that x86 VMs use X64 (x86-64) PEI today and it works so the 32-bit/64-bit mix has nothing to do with UEFI/PI/edk2. In the PC ecosystem a single chipset family can power