[edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

[Andrew Fish via Groups.Io]

> On Oct 14, 2019, at 6:11 AM, Laszlo Ersek <lersek at redhat.com> wrote:
> 
> On 10/12/19 08:42, Andrew Fish wrote:
>> Laszlo,
>> 
>> For 2) this  is very unfortunate. I think the root cause is for those
>> of us who work on x86 hardware day to day we get programed that
>> SEC/PEI is IA32 and DXE is X64, and this can lead to some unfortunate
>> coding outcomes.
> 
> First I was confused by this; I didn't understand why the "bitness" of
> SEC/PEI mattered here.
> 
> But, of course, you are right: if SEC/PEI are 32-bit, then the
> problematic relocations are never generated by the compiler in the first
> place.
> 

Laszlo,

The other "human" problem is people assume DXE always runs from memory so they think that patching is OK. I've even see people use IA32 to mean PEI on X64 platforms. So the implementation (32-bit PEI) leaks into the architecture. 

>> I'm guessing this code probably got ported from the DXE CPU driver or
>> some other place that had no XIP assumptions. One option vs. patching
>> is putting the relocations in the .data section. The only issue with
>> that could be the need to align sections on page boundaries and that
>> may take up too much space in XIP code. Perhaps we could only require
>> the .data section relocations for XCODE, and map them to .text for
>> the other toolchain?
> 
> In SEC, all sections of the binary are located in flash, aren't they?

Yes. 

> Why would it help if the relocations were placed in .data?

Sorry if I was unclear. The Xcode linker (ld64) enforces a macOS x86_64 ABI that makes it so even the image loader can't write the text section.  Thus you can't link an image that has relocations in the text section, and there is no flag to ld64 to turn this behavior off.  So the workaround is to generate code like the compiler and don't have any relocations in the text section.  Moving the relocation from the text to the data section is needed to make the Xcode linker (ld64) link the code. if there are relocations in the text section then the link will fail on Xcode builds. 

When you are writing assembly code there is no restriction about placing code in the data section. Generally we try to fix issues by converting the code to use PC relative addressing, but a quick and dirty fix is to change the code over to the data section.  The cleaner solution is to have a global in the data section that contains the relocatable address, and that is like the simple example of the C code global I sent out. 

> I'm reminded
> of global variables in SEC, and those are not writable in SEC either.
> (At least on QEMU.) I'm uncertain if this is somehow connected to
> Cache-as-RAM, but if it is: QEMU does not support Cache-as-RAM.
> 

For SEC the relocations would have been applied at build time. The SEC will have been linked at around zero, and when it was placed in the FV it would have been relocated to its XIP location. For code running from memory the EFI PE/COFF loader would apply the relocations as part of loading the image.  But non of the above works if your build fails due to a linker error :(. 

Thanks,

Andrew Fish


> Thanks
> Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48935): https://edk2.groups.io/g/devel/message/48935
Mute This Topic: https://groups.io/mt/34203585/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-