From: Daniel Kiper <daniel.kiper@oracle.com> To: Arvind Sankar <nivedita@alum.mit.edu> Cc: Ross Philipson <ross.philipson@oracle.com>, linux-kernel@vger.kernel.org, x86@kernel.org, iommu@lists.linux-foundation.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, luto@amacapital.net, trenchboot-devel@googlegroups.com Subject: Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub Date: Thu, 15 Oct 2020 20:26:54 +0200 [thread overview] Message-ID: <20201015182654.lgtht5fd2aaunczu@tomti.i.net-space.pl> (raw) In-Reply-To: <d34c189c-4528-0458-0b84-cfd36dc068b3@oracle.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Kiper <daniel.kiper@oracle.com> To: Arvind Sankar <nivedita@alum.mit.edu> Cc: linux-doc@vger.kernel.org, dpsmith@apertussolutions.com, Ross Philipson <ross.philipson@oracle.com>, x86@kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net, iommu@lists.linux-foundation.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, linux-integrity@vger.kernel.org, trenchboot-devel@googlegroups.com, tglx@linutronix.de Subject: Re: [PATCH 07/13] x86: Secure Launch kernel early boot stub Date: Thu, 15 Oct 2020 20:26:54 +0200 [thread overview] Message-ID: <20201015182654.lgtht5fd2aaunczu@tomti.i.net-space.pl> (raw) In-Reply-To: <d34c189c-4528-0458-0b84-cfd36dc068b3@oracle.com> 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 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-10-15 18:27 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-24 14:58 [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 01/13] x86: Secure Launch Kconfig Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-25 2:08 ` Randy Dunlap 2020-09-25 2:08 ` Randy Dunlap 2020-09-25 14:59 ` Ross Philipson 2020-09-25 14:59 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 02/13] x86: Secure Launch main header file Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 03/13] x86: Add early SHA support for Secure Launch early measurements Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-29 17:26 ` Jason Andryuk 2020-09-29 17:26 ` Jason Andryuk 2020-09-24 14:58 ` [PATCH 04/13] x86: Add early TPM TIS/CRB interface support for Secure Launch Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 " Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-25 5:43 ` Jarkko Sakkinen 2020-09-25 5:43 ` Jarkko Sakkinen 2020-09-29 23:47 ` Daniel P. Smith 2020-09-29 23:47 ` Daniel P. Smith 2020-09-30 3:19 ` Jarkko Sakkinen 2020-09-30 3:19 ` Jarkko Sakkinen 2020-09-30 3:24 ` Jarkko Sakkinen 2020-09-30 3:24 ` Jarkko Sakkinen 2021-01-20 0:33 ` Daniel P. Smith 2021-01-20 0:33 ` Daniel P. Smith 2020-09-24 14:58 ` [PATCH 06/13] x86: Add early general TPM " Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 07/13] x86: Secure Launch kernel early boot stub Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 17:38 ` Arvind Sankar 2020-09-24 17:38 ` Arvind Sankar 2020-09-25 14:56 ` Ross Philipson 2020-09-25 14:56 ` Ross Philipson 2020-09-25 19:18 ` Arvind Sankar 2020-09-25 19:18 ` Arvind Sankar 2020-09-29 14:03 ` Ross Philipson 2020-09-29 14:03 ` Ross Philipson 2020-09-29 14:53 ` Arvind Sankar 2020-09-29 14:53 ` Arvind Sankar 2020-10-15 18:26 ` Daniel Kiper [this message] 2020-10-15 18:26 ` Daniel Kiper 2020-10-16 20:51 ` Arvind Sankar 2020-10-16 20:51 ` Arvind Sankar 2020-10-19 14:38 ` Ross Philipson 2020-10-19 14:38 ` Ross Philipson 2020-10-19 17:06 ` Arvind Sankar 2020-10-19 17:06 ` Arvind Sankar 2020-10-19 19:00 ` Ross Philipson 2020-10-19 19:00 ` Ross Philipson 2020-10-19 14:51 ` Daniel Kiper 2020-10-19 14:51 ` Daniel Kiper 2020-10-19 17:18 ` Arvind Sankar 2020-10-19 17:18 ` Arvind Sankar 2020-10-21 15:28 ` Daniel Kiper 2020-10-21 15:28 ` Daniel Kiper 2020-10-21 16:18 ` Arvind Sankar 2020-10-21 16:18 ` Arvind Sankar 2020-10-21 20:36 ` Ross Philipson 2020-10-21 20:36 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 08/13] x86: Secure Launch kernel late " Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 09/13] x86: Secure Launch SMP bringup support Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 10/13] x86: Secure Launch adding event log securityfs Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 11/13] kexec: Secure Launch kexec SEXIT support Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 12/13] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-24 14:58 ` [PATCH 13/13] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson 2020-09-24 14:58 ` Ross Philipson 2020-09-25 5:30 ` [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support Jarkko Sakkinen 2020-09-25 5:30 ` Jarkko Sakkinen 2020-09-25 21:32 ` Daniel P. Smith 2020-09-25 21:32 ` Daniel P. Smith 2020-09-27 23:59 ` Jarkko Sakkinen 2020-09-27 23:59 ` Jarkko Sakkinen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201015182654.lgtht5fd2aaunczu@tomti.i.net-space.pl \ --to=daniel.kiper@oracle.com \ --cc=bp@alien8.de \ --cc=dpsmith@apertussolutions.com \ --cc=hpa@zytor.com \ --cc=iommu@lists.linux-foundation.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mingo@redhat.com \ --cc=nivedita@alum.mit.edu \ --cc=ross.philipson@oracle.com \ --cc=tglx@linutronix.de \ --cc=trenchboot-devel@googlegroups.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.