linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ross Philipson <ross.philipson@oracle.com>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Daniel Kiper <daniel.kiper@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: Mon, 19 Oct 2020 15:00:33 -0400	[thread overview]
Message-ID: <aeb92fc9-535d-8310-238c-f8a738d60acb@oracle.com> (raw)
In-Reply-To: <20201019170615.GB2701355@rani.riverdale.lan>

On 10/19/20 1:06 PM, Arvind Sankar wrote:
> On Mon, Oct 19, 2020 at 10:38:08AM -0400, Ross Philipson wrote:
>> On 10/16/20 4:51 PM, Arvind Sankar wrote:
>>> On Thu, Oct 15, 2020 at 08:26:54PM +0200, Daniel Kiper wrote:
>>>>
>>>> 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
>>>
>>> What exactly is the size you need here? Is it just the size of the
>>> protected mode image, that's startup_32 to _edata. Or is it the size of
>>
>> It is the size of the protected mode image. Though how to reference
>> those symbols to get the size might all more relocation issues.
>>
> 
> Ok, then I think mleh_rva(_edata) should get you that -- I assume you
> don't want to include the uninitialized data in the size? The kernel
> will access memory beyond _edata (upto the init_size in the setup
> header), but that's not part of the image itself.

Yea we basically want the size of the image. There is nothing to measure
beyond the image as loaded into memory by the bootloader. rva(_edata)
seems to be the ticket.

Thanks
Ross

> 


  reply	other threads:[~2020-10-19 19:02 UTC|newest]

Thread overview: 40+ 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 ` [PATCH 01/13] x86: Secure Launch Kconfig Ross Philipson
2020-09-25  2:08   ` Randy Dunlap
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 ` [PATCH 03/13] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
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 ` [PATCH 05/13] x86: Add early TPM1.2/TPM2.0 " Ross Philipson
2020-09-25  5:43   ` Jarkko Sakkinen
2020-09-29 23:47     ` Daniel P. Smith
2020-09-30  3:19       ` Jarkko Sakkinen
2020-09-30  3:24         ` Jarkko Sakkinen
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 ` [PATCH 07/13] x86: Secure Launch kernel early boot stub Ross Philipson
2020-09-24 17:38   ` Arvind Sankar
2020-09-25 14:56     ` Ross Philipson
2020-09-25 19:18       ` Arvind Sankar
2020-09-29 14:03         ` Ross Philipson
2020-09-29 14:53           ` Arvind Sankar
2020-10-15 18:26           ` Daniel Kiper
2020-10-16 20:51             ` Arvind Sankar
2020-10-19 14:38               ` Ross Philipson
2020-10-19 17:06                 ` Arvind Sankar
2020-10-19 19:00                   ` Ross Philipson [this message]
2020-10-19 14:51               ` Daniel Kiper
2020-10-19 17:18                 ` Arvind Sankar
2020-10-21 15:28                   ` Daniel Kiper
2020-10-21 16:18                     ` Arvind Sankar
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 ` [PATCH 09/13] x86: Secure Launch SMP bringup support Ross Philipson
2020-09-24 14:58 ` [PATCH 10/13] x86: Secure Launch adding event log securityfs Ross Philipson
2020-09-24 14:58 ` [PATCH 11/13] kexec: Secure Launch kexec SEXIT support 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 ` [PATCH 13/13] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2020-09-25  5:30 ` [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support Jarkko Sakkinen
2020-09-25 21:32   ` Daniel P. Smith
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=aeb92fc9-535d-8310-238c-f8a738d60acb@oracle.com \
    --to=ross.philipson@oracle.com \
    --cc=bp@alien8.de \
    --cc=daniel.kiper@oracle.com \
    --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=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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).