From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81746C2D0E5 for ; Thu, 26 Mar 2020 21:28:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5301520714 for ; Thu, 26 Mar 2020 21:28:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="M6cg4sv8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726363AbgCZV2k (ORCPT ); Thu, 26 Mar 2020 17:28:40 -0400 Received: from mail-il1-f194.google.com ([209.85.166.194]:34042 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726359AbgCZV2i (ORCPT ); Thu, 26 Mar 2020 17:28:38 -0400 Received: by mail-il1-f194.google.com with SMTP id t11so6884886ils.1 for ; Thu, 26 Mar 2020 14:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Btlqx21eu40zUkcej/V6liXdJs8HK+Dpn/OJAl+X7mA=; b=M6cg4sv8ajLQueUJZXq4N/kjX221+tiJF3yQSbWclKBVnWsv+Ff2zDfM6Bxb6emo97 LQ1F9sPt3GWYLMPIdeL4dgPAXK5i4ESgbkSvjnUj5ytNaBhoyXlsz6x5It7brFjgReOv n3MYFBCKdFqDEPs2O4hZKMy8DL1bmo9gMFqgPuJ/hsxgK/RcKyParZEVp1UdPgnkc0NK ypUXfY0uVphJ5BknZRjb/x1FhKKT3ZFlCaklkosor2ursaMGsd8dvOP3HzYYhh7Juy2F ayKp0BZ7fvweMRKcyB6i+xLNqNgAu+fvFuiwQOPjis10vBxB9LI0i1il4vufxE3hZufc TXAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Btlqx21eu40zUkcej/V6liXdJs8HK+Dpn/OJAl+X7mA=; b=AzoIyoC+r+3OXKv/6GY1B2ibvM82yJ2/KMEFh+un5JKCmGn8ps184ohmOpumBj8HnT 8kBQYO7YdaYVsiRktcu9L7hIUVYk4L7OECqb0JDxNB1wNNPWqmd/rzxWfMnrHIT3Sxlj SA7QmMi5YehWZNsKANYbB1uPtjG+ADCyKERYLfHH0FafgLqEhJmXjkGat7F2izvPbL/N n3E3PEDDUVoOn4usrH3ehODcGfqtak0kFwUyMDcG/t+8ssECCSkqvDtrgCGETzJOEFAL v3SYKAzrD3zh+Jx0Vrz3P0CQ/dnbzDD8gUQGTmnpnsRTPzlHFVsWDMrH6RPi6nlm7G+N pfaQ== X-Gm-Message-State: ANhLgQ3jO0Whn3vbhFPVCGZlaUEB5gzMmNNUKvEk0R+oXZWyWhmOMSQ9 92LupoxZiG3KK/RiPskbJ7DaYY9n2EPX0Ofn6H0nvg== X-Google-Smtp-Source: ADFU+vtLzOd32bY6WCTbTFgGTLvCSJZvih2LXQlPgGOADfvm83VghlrezAbG6LvoVKJt3DkATZXqLyP+LNg02NhPwmE= X-Received: by 2002:a92:8384:: with SMTP id p4mr11224795ilk.16.1585258116250; Thu, 26 Mar 2020 14:28:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Garrett Date: Thu, 26 Mar 2020 14:28:25 -0700 Message-ID: Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support To: Andy Lutomirski Cc: Daniel Kiper , Ross Philipson , Linux Kernel Mailing List , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, "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.cooper3@citrix.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, Mar 26, 2020 at 2:07 PM Andy Lutomirski wrote= : > > On Mar 26, 2020, at 1:40 PM, Matthew Garrett wrote: > > > > =EF=BB=BFOn Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski wrote: > >> As a straw-man approach: make the rule that we never call EFI after se= cure launch. Instead we write out any firmware variables that we want to ch= ange on disk somewhere. When we want to commit those changes, we reboot, c= ommit 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=E2=80=99m not familiar with this. https://trustedcomputinggroup.org/wp-content/uploads/TCG_PlatformResetAttac= kMitigationSpecification_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. > > 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=E2=80=99re misunderstanding my suggestion. I=E2=80=99m suggest= ing that we hibernate the whole running system to memory (more like kexec j= ump than hibernate) and authenticated-encrypt the whole thing (including us= er 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.