Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 0/1] [RFC] Secure Launch boot protocol
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
References: <20190311150423.15979-1-ross.philipson@oracle.com>
From:   "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com>
Date:   Thu, 28 Mar 2019 11:15:53 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <20190311150423.15979-1-ross.philipson@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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