Received: by 2002:a17:90a:1609:0:0:0:0 with SMTP id n9csp2471715pja; Thu, 26 Mar 2020 16:05:10 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtE+IXlzhwtrau14GTdiKuw5eEm6Y+ui9IVe0ZIZnpA0CtFds29gIRd2KwjMiIIafn5rLyo X-Received: by 2002:a05:6830:199:: with SMTP id q25mr8740160ota.341.1585263910531; Thu, 26 Mar 2020 16:05:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585263910; cv=none; d=google.com; s=arc-20160816; b=RjOadbT6OA0FOEA/CxusX3rLHbrPA4mtbBTG5tu7FjnZbw/eAunvpO/1KlnhR8YnNJ ZgQjRiaOoUZN1m0meLCn+9nfysX/HMBYtYBAA9yxsYuQt6tz4pLp5lmgOT1ePB590Yti r5ggvxy3WAjqCVb95Wc1GNdRLPlCvIhDnNneek26BpRHCQ8Qbi5plVOW905H35sDbFtD EABbARO1vubmTizn7qDcLSW/Qkhm3RDlNxYF+ivFM2H9y9/ta81DsVLdV+xbQVEgYW56 id8j+64xDSZ/XHCU/lPBYLw5tNYTOXWPhLpcj9yDaTniaf7VSjeOgbvh1bsrtcGgQho7 K53A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=l+2RMV9dD/OUOUilGkUxrXOKcvqVgnSzx11vHhpRdKM=; b=EL2f3vCXxE/1A4EotP0KsnSJ0/Y8TNHTzZpEveh5XjvXHQzJ7lRCXdebz/TKEpGxNM vHAen2hZQ1Jz7aQsRz7LoDmGCo6e8T01Lf9vxrH9DKEd35hDvI8vg5wpDYoQN0JpSeH8 /tAdqrNk2TVK0DqhwHq0+iex315WKKeu/O1ywueP8Rvd4B2iFJNlab36Jqs+XDAC0hRT D8mtlgb5fO0sPCFltJcJ+S+tqm8EN0QngAkyp9eT0SBufuT6cuGjRGI5PurLj+hB7TSP M5cgHSvxPaDztjN9PFxPxtQLORA1TKkp7RnhTUwCmgOEs0SmjqBkK0Q6l+bjuMwx6yAt nZpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oEYLp2wd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2si1621420otl.298.2020.03.26.16.04.56; Thu, 26 Mar 2020 16:05:10 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oEYLp2wd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726954AbgCZXE1 (ORCPT + 99 others); Thu, 26 Mar 2020 19:04:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:60622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726296AbgCZXE1 (ORCPT ); Thu, 26 Mar 2020 19:04:27 -0400 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 76A7220857 for ; Thu, 26 Mar 2020 23:04:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585263865; bh=6pcjGJJSGR1d/J2j5J8p6DT7L5qF5IgIjSvQ+yDaIIg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oEYLp2wdyBbzCEfC/0Fe4pQu7k1S9tcKac7S3Jr4BINVZMcUNi0nnNz4j93y5CSzp HoEJDghg/oSGbv0f8vURN/zNYQfFwxTDH70w4hpQkZ81oDA524/MgyGhp576+c9HbB spBvzLkZc9Y5uGibJNZ1BFfOwW9e/RZC4TMa/Qi8= Received: by mail-wm1-f47.google.com with SMTP id c81so9404241wmd.4 for ; Thu, 26 Mar 2020 16:04:25 -0700 (PDT) X-Gm-Message-State: ANhLgQ2PRqxuv0+ppHV31K+pMUl8gydbJB/a7QlLnaI4++xjANuVAXg4 InXSPWI82Y5u4Z6zfHLUtSP22/UdR9YHSulvROBWwA== X-Received: by 2002:a1c:f407:: with SMTP id z7mr2236114wma.36.1585263863761; Thu, 26 Mar 2020 16:04:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Thu, 26 Mar 2020 16:04:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support To: Matthew Garrett Cc: Andy Lutomirski , Daniel Kiper , Ross Philipson , Linux Kernel Mailing List , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , "Daniel P. Smith" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , trenchboot-devel@googlegroups.com, Ard Biesheuvel , leif@nuviainc.com, eric.snowberg@oracle.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, michal.zygowski@3mdeb.com, James Bottomley , Andrew Cooper Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2020 at 4:00 PM Matthew Garrett wrote: > > On Thu, Mar 26, 2020 at 3:52 PM Andy Lutomirski wrote: > > > > On Thu, Mar 26, 2020 at 2:28 PM Matthew Garrett 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?