mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Ross Philipson <ross.philipson@oracle.com>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, corbet@lwn.net, konrad.wilk@oracle.com,
	kanth.ghatraju@oracle.com, daniel.kiper@oracle.com,
	boris.ostrovsky@oracle.com, dpsmith@apertussolutions.com
Subject: Re: [PATCH 0/1] [RFC] Secure Launch boot protocol
Date: Thu, 28 Mar 2019 11:15:53 -0700	[thread overview]
Message-ID: <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com> (raw)
In-Reply-To: <20190311150423.15979-1-ross.philipson@oracle.com>

So, per our conversation today, lets create a new, readonly, data structure
pointed to by a single field in setup_header, in order to preserve what little
space we have left in that structure (a whopping 24 bytes...)

The new data structure will have a header consisting of a magic number and a
length field; if we want to be really paranoid we could add a checksum/crc.

The existence of this new readonly structure will be announced by bumping the
boot protocol to 2.15.

The presence of your new boot launch capability (trenchboot) will be indicated
by a new bit in xloadflags.

I thought hard about this, and I have come to the conclusion that the new
structure is better off in the .rodata section of the compressed kernel rather
than in the setup area, for the following reasons, some of which are
theoretical and unlikely to apply anywhere in the near future, but don't
actually hurt to address right off the bat:

a. The future size of the structure would not be artificially constrained by
   the 32K hard limit on the setup area;
b. It is one less level of indirection in the build tools;
c. It adds a possibly unnecessary dependency on the setup area, which could
   possibly be awkward for some boot loaders (unlikely, but...);
d. It would allow this new structure to also carry information that might be
   useful to the decompressor for whatever reason.

	-hpa

  parent reply	other threads:[~2019-03-28 19:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 15:04 Ross Philipson
2019-03-11 15:04 ` [PATCH 1/1] x86: " Ross Philipson
2019-03-12 17:34   ` hpa
2019-03-14 18:53     ` Konrad Rzeszutek Wilk
2019-03-15  2:21       ` hpa
2019-03-28 18:15 ` H. Peter Anvin [this message]
2019-03-28 18:37   ` [PATCH 0/1] [RFC] " Daniel Kiper

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=54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com \
    --to=hpa@zytor.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.kiper@oracle.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --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

all inboxes | Powered by JetHome®