Open tklengyel opened 6 years ago
Quick update. It seems like the shim actually forgos copying the .reloc
section completely as it's marked discardable and thus Xen just sees uninitialized memory when it's trying to read it. But then again, Xen does expect to do relocation by itself, so it's actually better to just skip the shim doing any of that. Would there be any interest in making that configurable if I were to send in a patch?
That seems weird - shim is trying to do the same thing the normal edk2 loader would do. Why does this work with that code and not this code? Is edk2 not doing the relocation and discarding the section? It's clearly the right thing to do as per the PE spec.
I'm not sure. Xen hardcodes some sanity-checks specific to the presence of the .reloc
section (https://github.com/tklengyel/xen/blob/master/xen/common/efi/boot.c#L1153) and then does the relocation itself (https://github.com/tklengyel/xen/blob/master/xen/arch/x86/efi/efi-boot.h#L234).
Hi all, I'm currently experimenting with booting Xen through the latest version of shim and I've ran into a couple issue. ~First, the line
li->ImageBase = buffer;
makes xen.efi throw up with "Unsupported relocation type" errors. The relocation types Xen complained about were quite obviously nonsensical and with the ImageBase not being fixed up by shim Xen seems to be able to get pass that problem. However, it is unable to locate the shim protocol with the guid afterwards. Does anyone have any pointers on what might be going wrong?~ That actually didn't do what I thought it did, the firmware just fall back to another Xen entry, that's why Xen couldn't find the shim.So the problem that I have is that if I boot xen.efi through the shim, Xen complains about "Unsupported relocation type". I had it print the relocation type it finds for the section and it does look nonsensical (like 13). Anyone has any tips on what might be going wrong?
Thanks!