From: "Daniel P. Smith" <firstname.lastname@example.org> To: Andy Lutomirski <email@example.com>, Matthew Garrett <firstname.lastname@example.org> Cc: Daniel Kiper <email@example.com>, Ross Philipson <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, the arch/x86 maintainers <firstname.lastname@example.org>, "open list:DOCUMENTATION" <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, "H. Peter Anvin" <email@example.com>, firstname.lastname@example.org, Ard Biesheuvel <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, James Bottomley <James.Bottomley@hansenpartnership.com>, Andrew Cooper <email@example.com> Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Date: Thu, 26 Mar 2020 20:01:30 -0400 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CALCETrVwqtpwBigzHJU7so=q0rJ2tUfxGKCJE7oY2RJA156wHg@mail.gmail.com> On 3/26/20 7:04 PM, Andy Lutomirski wrote: > On Thu, Mar 26, 2020 at 4:00 PM Matthew Garrett <email@example.com> wrote: >> >> On Thu, Mar 26, 2020 at 3:52 PM Andy Lutomirski <firstname.lastname@example.org> wrote: >>> >>> On Thu, Mar 26, 2020 at 2:28 PM Matthew Garrett <email@example.com> wrote: >>>> 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. >> >> Mm, yes, this one might be something we can just ignore in the TXT case. >> >>>> 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. >> >> That presumably depends on how much state is in the measured region - >> we can't just measure the code in order to assert that we're secure. >> >>> 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. >> >> I'm fine with a solution that involves jumping through some hoops, but >> it feels like simply supporting measuring and passing through the >> runtime services would be fine - if you want to keep them outside the >> TCB, build a kernel that doesn't have EFI runtime service support and >> skip that measurement? > > I'm certainly fine with the kernel allowing a mode like this. At the > end of the day, anyone building something based on secure launch > should know what they're doing. > > On the other hand, unless I've missed something, we need to support a > transition from "secure" measured mode to unmeasured and back if we're > going to support secure launch and S3 at the same time. But maybe S3 > is on its way out in favor of suspend-to-idle? > I didn't comment earlier on S3 and my view is that it is horrible when trying to deal with it from a security perspective. As a result I have been driven to the belief that you cannot assume your security posture is the same after S3 as it was before or that you even know what your posture is. On Intel we have the SEXIT instruction to signal that we are no longer in SMX which, in theory, blocks modification of DRTM PCRs. Thus SEXIT should be called before S3 and then when you come back one needs to then re-launch to get back to a known state of integrity.
next prev parent reply index Thread overview: 43+ 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-05-11 19:00 ` Daniel P. Smith 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 [this message] 2020-03-26 23:50 ` Daniel P. Smith 2020-05-11 19:00 ` Daniel P. Smith 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=James.Bottomley@hansenpartnership.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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 \ email@example.com 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