Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub

[Daniel Kiper]

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