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] [thread-next>] [day] [month] [year] [list]

Message-ID: <54a6bc26-584f-322a-2089-be96472e2d4f@zytor.com>
Date:   Thu, 28 Mar 2019 11:15:53 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Ross Philipson <ross.philipson@...cle.com>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Cc:     x86@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        corbet@....net, konrad.wilk@...cle.com, kanth.ghatraju@...cle.com,
        daniel.kiper@...cle.com, boris.ostrovsky@...cle.com,
        dpsmith@...rtussolutions.com
Subject: Re: [PATCH 0/1] [RFC] Secure Launch boot protocol

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