From: Daniel Kiper <daniel.kiper@oracle.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ross Philipson <ross.philipson@oracle.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, corbet@lwn.net, konrad.wilk@oracle.com,
kanth.ghatraju@oracle.com, boris.ostrovsky@oracle.com,
dpsmith@apertussolutions.com
Subject: Re: [PATCH 0/1] [RFC] Secure Launch boot protocol
Date: Thu, 28 Mar 2019 19:37:58 +0100 [thread overview]
Message-ID: <20190328183758.zv2xtqrdrehwpcpp@tomti.i.net-space.pl> (raw)
In-Reply-To: <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com>
On Thu, Mar 28, 2019 at 11:15:53AM -0700, H. Peter Anvin wrote:
> 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.
Thank you for your help. I will try to post the patches next week.
Daniel
prev parent reply other threads:[~2019-03-28 18:38 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 ` [PATCH 0/1] [RFC] " H. Peter Anvin
2019-03-28 18:37 ` Daniel Kiper [this message]
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=20190328183758.zv2xtqrdrehwpcpp@tomti.i.net-space.pl \
--to=daniel.kiper@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dpsmith@apertussolutions.com \
--cc=hpa@zytor.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®