Relocate FVs to claim extra space from ME region.

[persmule]

With me_cleaner, a lot of ROM space (several MiB) could be freed from ME region and potentially used by BIOS region instead.

Is it possible to relocate FVs (especially the DXE FV) inside the enlarged BIOS region to claim these space? And if possible, how to do that?

I have investigated a lot about the build process of EDK2, only to find there should be an FDF to record all the FVs' offset and size, but failed to find how the FDF is built to binary and stored in the resulted FD image.

[vejmarie]

Le 31/05/2018 à 11:42, persmule a écrit :

With me_cleaner, a lot of ROM space (several MiB) could be freed from ME region and potentially used by BIOS region instead. Is it possible to relocate FVs (especially the DXE FV) inside the enlarged BIOS region to claim these space? And if possible, how to do that? I have investigated a lot about the build process of EDK2, only to find there should be an FDF to record all the FVs' offset and size, but failed to find how the FDF is built to binary and stored in the resulted FD image. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhW6b5qkF8uNl-f5QNBDBuXNU1Mp2tLks5t37rvgaJpZM4UUvHe>.

We did work on such exercise for a specific project. I don't think we did publish the results yet, but it might be coming up soon. We wanted to do the same thing than you did propose, but have faced strong issues, where a lot of hardcoded address space (or offset) are standing into the PEI and DXE code (PEI is not rellocatable, DXE is supposed to be). So we decided to adopt a different strategy, as our rellocated image was not working. We created a new FV which is using the empty space, and added it to the Flash volume descriptor, without success (roughly the original AMI BIOS was not mounting it and DXECore was not loading the DXE drivers we were pushing into it). Tram Hudson, wrote to address that case a special DXE driver which is super small and can mostly fit into any current DXE FV. That DXE Driver is called FvLoader, and is "mounting" our newly created Fv giving the possibility to use the extra space. I know this approach is a workaround but it has proven to be successfull on at least one system, it is quite pretty. If you want to use the extra space to make fit a big unitary blob, that approach won't work, but if your intend is to add a couple of DXE drivers it could be suitable. Just let us know ! vejmarie

[persmule]

@vejmarie Thank you very much, but I have a bit more questions:

0. Does PEI already know where DXE FV should be when its own FV are generated, or the FV layout is corrected when constructing FD?

1. Does FV layout used by PEI and/or DXE initially come from FDF? If so, how is the layout coded into PEI and/or DXE modules? e.g. via auto-generated source files containing global variables?

[vejmarie]

Hi, SeC Core ends most of the time by a jump into DXECore, and unfortunatly or most of the time the jump is a direct address within memory space (aka 4GB - xxxx) which is computed based on a physical offset into the flash. So SeC Core is probably not using FD but all of this is assumption made from reverse engineering So roughly the answer to 0 is Yes if my assumption is good PEI must know where DXE FV stands as to handover to DXECore. Answer to 1, is probably more tricky. I don't think that PEI is knowing anything regarding the FD, but I might be totally wrong. PCH is mapping the flash, and chips boostrap on the vector contained into PEI area (4GB - 16 if I am not wrong). FD first usage is probably at DXE level. From what I learnt, I suspect that most of the stuff is "hard coded" or deducted at compilation time. vejmarie Le 31/05/2018 à 13:43, persmule a écrit :

…

@vejmarie <https://github.com/vejmarie> Thank you very much, but I have a bit more questions: 0. Does PEI already know where DXE FV should be when its own FV are generated, or the FV layout is corrected when constructing FD? 1. Does FV layout used by PEI and/or DXE initially come from FDF? If so, how is the layout coded into PEI and/or DXE modules? e.g. via auto-generated source files containing global variables? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhW6YIiHZvkFRrawdcgVeGvBEJ3v1nIks5t39d8gaJpZM4UUvHe>.

[osresearch]

Jean-Marie is correct (with one minor correction -- SecCore jumps into PeiCore, which eventually hands control to DxeCore). On most platforms these addresses and lengths seem to be hard coded into the PEI core for some reason, rather than scanning the ROM for them. These are typically stored in "compile time constant PCD" values, so they end up scattered throughout the various modules. On some platforms (like the MinPlatform MtOlympus) the PEI FV is not actually known at compile time, so there is a post-build step that binary patch the seccore to find it. Yeah...

I'm working on replacing the Linux BDS patch with a separate DXE module that does the minimum BDS stuff, as well as allowing us to add in new firmware volumes, remap the SPI flash as necessary and retrieve kernel command line parameters from the UEFI nvram store. https://github.com/osresearch/linuxboot/blob/bds/dxe/linuxboot.c

[JulienVdG]

I polished that work in here : #40
note that I'm not using me_cleaner but just resizing the me region to it's actual use of flash space.