On Tue, Sep 29, 2020 at 10:03:47AM -0400, Ross Philipson wrote: > On 9/25/20 3:18 PM, Arvind Sankar wrote:
[...] > > You should see them if you do > > readelf -r arch/x86/boot/compressed/vmlinux > > > > In terms of the code, things like: > > > > addl %ebx, (sl_gdt_desc + 2)(%ebx) > > > > will create a relocation, because the linker interprets this as wanting > > the runtime address of sl_gdt_desc, rather than just the offset from > > startup_32. > > > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/boot/compressed/head_64.S*n48__;Iw!!GqivPVa7Brio!JpZWv1cCPZdjD2jbCCGT7P9UIVl_lhX7YjckAnUcvi927jwZI7X3nX0MpIAZOyktJds$ > > > > has a comment with some explanation and a macro that the 32-bit code in > > startup_32 uses to avoid creating relocations. > > > > Since the SL code is in a different assembler file (and a different > > section), you can't directly use the same macro. I would suggest getting > > rid of sl_stub_entry and entering directly at sl_stub, and then the code > > in sl_stub.S can use sl_stub for the base address, defining the rva() > > macro there as > > > > #define rva(X) ((X) - sl_stub) > > > > You will also need to avoid initializing data with symbol addresses. > > > > .long mle_header > > .long sl_stub_entry > > .long sl_gdt > > > > will create relocations. The third one is easy, just replace it with > > sl_gdt - sl_gdt_desc and initialize it at runtime with > > > > leal rva(sl_gdt_desc)(%ebx), %eax > > addl %eax, 2(%eax) > > lgdt (%eax) > > > > The other two are more messy, unfortunately there is no easy way to tell > > the linker what we want here. The other entry point addresses (for the > > EFI stub) are populated in a post-processing step after the compressed > > kernel has been linked, we could teach it to also update kernel_info. > > > > Without that, for kernel_info, you could change it to store the offset > > of the MLE header from kernel_info, instead of from the start of the > > image. > > > > For the MLE header, it could be moved to .head.text in head_64.S, and > > initialized with > > .long rva(sl_stub) > > This will also let it be placed at a fixed offset from startup_32, so > > that kernel_info can just be populated with a constant. I am discussing with Ross the other option. We can create .rodata.mle_header section and put it at fixed offset as kernel_info is. So, we would have, e.g.: arch/x86/boot/compressed/vmlinux.lds.S: .rodata.kernel_info KERNEL_INFO_OFFSET : { *(.rodata.kernel_info) } ASSERT(ABSOLUTE(kernel_info) == KERNEL_INFO_OFFSET, "kernel_info at bad address!") .rodata.mle_header MLE_HEADER_OFFSET : { *(.rodata.mle_header) } ASSERT(ABSOLUTE(mle_header) == MLE_HEADER_OFFSET, "mle_header at bad address!") arch/x86/boot/compressed/sl_stub.S: #define mleh_rva(X) (((X) - mle_header) + MLE_HEADER_OFFSET) .section ".rodata.mle_header", "a" SYM_DATA_START(mle_header) .long 0x9082ac5a /* UUID0 */ .long 0x74a7476f /* UUID1 */ .long 0xa2555c0f /* UUID2 */ .long 0x42b651cb /* UUID3 */ .long 0x00000034 /* MLE header size */ .long 0x00020002 /* MLE version 2.2 */ .long mleh_rva(sl_stub_entry) /* Linear entry point of MLE (virt. address) */ .long 0x00000000 /* First valid page of MLE */ .long 0x00000000 /* Offset within binary of first byte of MLE */ .long 0x00000000 /* Offset within binary of last byte + 1 of MLE */ .long 0x00000223 /* Bit vector of MLE-supported capabilities */ .long 0x00000000 /* Starting linear address of command line (unused) */ .long 0x00000000 /* Ending linear address of command line (unused) */ SYM_DATA_END(mle_header) Of course MLE_HEADER_OFFSET has to be defined as a constant somewhere. Anyway, is it acceptable? There is also another problem. We have to put into mle_header size of the Linux kernel image. Currently it is done by the bootloader but I think it is not a role of the bootloader. The kernel image should provide all data describing its properties and do not rely on the bootloader to do that. Ross and I investigated various options but we did not find a good/simple way to do that. Could you suggest how we should do that or at least where we should take a look to get some ideas? Daniel
