Linux-Doc Archive on lore.kernel.org
 help / color / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Andy Lutomirski <luto@kernel.org>, Matthew Garrett <mjg59@google.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	Ross Philipson <ross.philipson@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	trenchboot-devel@googlegroups.com,
	Ard Biesheuvel <ardb@kernel.org>,
	leif@nuviainc.com, eric.snowberg@oracle.com,
	piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com,
	michal.zygowski@3mdeb.com,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
Date: Thu, 26 Mar 2020 19:50:09 -0400
Message-ID: <e9ff3b26-7103-6b56-611a-09ad13a8c96b@apertussolutions.com> (raw)
In-Reply-To: <CALCETrU4W7q=QyTX_iq_kN4nVK58WoOD0F_NBt7z8p7xiE7hfA@mail.gmail.com>

On 3/26/20 6:52 PM, Andy Lutomirski wrote:
> On Thu, Mar 26, 2020 at 2:28 PM Matthew Garrett <mjg59@google.com> wrote:
>>
>> On Thu, Mar 26, 2020 at 2:07 PM Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Mar 26, 2020, at 1:40 PM, Matthew Garrett <mjg59@google.com> wrote:
>>>>
>>>> On Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski <luto@amacapital.net> wrote:
>>>>> As a straw-man approach: make the rule that we never call EFI after secure launch. Instead we write out any firmware variables that we want to change on disk somewhere.  When we want to commit those changes, we reboot, commit the changes, and re-launch. Or we deactivate the kernel kexec-style, seal the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, and continue on our merry way.
>>>>
>>>> That breaks the memory overwrite protection code, where a variable is
>>>> set at boot and cleared on a controlled reboot.
>>>
>>> Can you elaborate?  I’m not familiar with this.
>>
>> https://trustedcomputinggroup.org/wp-content/uploads/TCG_PlatformResetAttackMitigationSpecification_1.10_published.pdf
>> - you want to protect in-memory secrets from a physically present
>> attacker hitting the reset button, booting something else and just
>> dumping RAM. This is avoided by setting a variable at boot time (in
>> the boot stub), and then clearing it on reboot once the secrets have
>> been cleared from RAM. If the variable isn't cleared, the firmware
>> overwrites all RAM contents before booting anything else.
> 
> I admit my information is rather dated, but I'm pretty sure that at
> least some and possibly all TXT implementations solve this more
> directly.  In particular, as I understand it, when you TXT-launch
> anything, a nonvolatile flag in the chipset is set.  On reboot, the
> chipset will not allow access to memory *at all* until an
> authenticated code module wipes memory and clears that flag.
> 
> If your computer advertises TXT support but is missing that ACM, you
> are SOL.  I learned about this when I bricked my old Lenovo laptop. As
> far as I can tell, the flag was set, but the Lenovo BIOS didn't know
> how to wipe memory.  Whoops!
> 

You are correct, there is the SECRETS flag. If it set during DL then
when the system comes back around to the BIOS ACM and it finds the flag
set it, it will take action. The exact details are locked up under NDA
but you could take a look at the recent work in coreboot to add TXT
support to see how they handled it.

>>
>>>> As for the second approach - how would we
>>>> verify that the EFI code hadn't modified any user pages? Those
>>>> wouldn't be measured during the second secure launch. If we're calling
>>>> the code at runtime then I think we need to assert that it's trusted.
>>>
>>> Maybe you’re misunderstanding my suggestion.  I’m suggesting that we hibernate the whole running system to memory (more like kexec jump than hibernate) and authenticated-encrypt the whole thing (including user memory) with a PCR-sealed key. We jump to a stub that zaps PCRs does EFI calls. Then we re-launch and decrypt memory.
>>
>> When you say "re-launch", you mean perform a second secure launch? I
>> think that would work, as long as we could reconstruct an identical
>> state to ensure that the PCR17 values matched - and that seems like a
>> hard problem.
> 
> Exactly.  I would hope that performing a second secure launch would
> reproduce the same post-launch PCRs as the first launch.  If the
> kernel were wise enough to record all PCR extensions, it could replay
> them.
> 
> (I can imagine an alternate universe in which the PCR extension used a
> more clever algorithm that allowed log-time fast forwarding.  As far
> as I know, this is not currently the case.)
> 
> In any case, I'm kind of with Daniel here.  We survived for quite a
> long time without EFI variables at all.  The ability to write them is
> nice, and we certainly need some way, however awkward, to write them
> on rare occasions, but I don't think we really need painless runtime
> writes to EFI variables.
> 



  parent reply index

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 19:43 Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 01/12] x86: Secure Launch Kconfig Ross Philipson
2020-03-26 18:06   ` Daniel Kiper
2020-03-26 19:42     ` Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 02/12] x86: Secure Launch main header file Ross Philipson
2020-03-26 19:00   ` Daniel Kiper
2020-03-25 19:43 ` [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2020-03-26  3:44   ` Andy Lutomirski
2020-03-26 22:49     ` Daniel P. Smith
2020-03-25 19:43 ` [RFC PATCH 04/12] x86: Add early TPM TIS/CRB interface support for Secure Launch Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 05/12] x86: Add early TPM1.2/TPM2.0 " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 06/12] x86: Add early general TPM " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 07/12] x86: Secure Launch kernel early boot stub Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 08/12] x86: Secure Launch kernel late " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 09/12] x86: Secure Launch SMP bringup support Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 10/12] x86: Secure Launch adding event log securityfs Ross Philipson
2020-03-25 20:21   ` Matthew Garrett
2020-03-25 21:43     ` Daniel P. Smith
2020-03-25 19:43 ` [RFC PATCH 11/12] kexec: Secure Launch kexec SEXIT support Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 12/12] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2020-03-25 20:29 ` [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Matthew Garrett
2020-03-25 22:51   ` Andy Lutomirski
2020-03-26 20:50     ` Daniel P. Smith
2020-03-26 23:13       ` Andy Lutomirski
2020-03-26 13:40   ` Daniel Kiper
2020-03-26 20:19     ` Matthew Garrett
2020-03-26 20:33       ` Andy Lutomirski
2020-03-26 20:40         ` Matthew Garrett
2020-03-26 20:59           ` Daniel P. Smith
2020-03-26 21:07           ` Andy Lutomirski
2020-03-26 21:28             ` Matthew Garrett
2020-03-26 22:52               ` Andy Lutomirski
2020-03-26 22:59                 ` Matthew Garrett
2020-03-26 23:04                   ` Andy Lutomirski
2020-03-27  0:01                     ` Daniel P. Smith
2020-03-26 23:50                 ` Daniel P. Smith [this message]
2020-03-26 20:50   ` Daniel P. Smith
2020-03-26 20:54     ` Matthew Garrett
2020-03-26 22:37       ` Daniel P. Smith
2020-03-26 22:41         ` Matthew Garrett
2020-03-26 23:55           ` Daniel P. Smith

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=e9ff3b26-7103-6b56-611a-09ad13a8c96b@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=daniel.kiper@oracle.com \
    --cc=eric.snowberg@oracle.com \
    --cc=hpa@zytor.com \
    --cc=krystian.hebel@3mdeb.com \
    --cc=leif@nuviainc.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=michal.zygowski@3mdeb.com \
    --cc=mingo@redhat.com \
    --cc=mjg59@google.com \
    --cc=piotr.krol@3mdeb.com \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=trenchboot-devel@googlegroups.com \
    --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

Linux-Doc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-doc/0 linux-doc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-doc linux-doc/ https://lore.kernel.org/linux-doc \
		linux-doc@vger.kernel.org
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-doc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git