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;
Date:   Thu, 28 Mar 2019 19:37:58 +0100
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
Message-ID: <20190328183758.zv2xtqrdrehwpcpp@tomti.i.net-space.pl>
References: <20190311150423.15979-1-ross.philipson@oracle.com>
 <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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