linux-kernel - Re: [PATCH 0/1] [RFC] Secure Launch boot protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190328183758.zv2xtqrdrehwpcpp@tomti.i.net-space.pl>
Date:   Thu, 28 Mar 2019 19:37:58 +0100
From:   Daniel Kiper <daniel.kiper@...cle.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Ross Philipson <ross.philipson@...cle.com>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        x86@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        corbet@....net, konrad.wilk@...cle.com, kanth.ghatraju@...cle.com,
        boris.ostrovsky@...cle.com, dpsmith@...rtussolutions.com
Subject: Re: [PATCH 0/1] [RFC] Secure Launch boot protocol

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