From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.16745.1671439990809162792 for ; Mon, 19 Dec 2022 00:53:11 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ChjAuqwm; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671439989; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l3RRzjf3PEVF0Y6mNVhwnMOwYxTciC9Wa0C13AYh4is=; b=ChjAuqwmlTYFfg6+e19l7qUlC4QISvBPspklfJctHa7sEsNZRdTEJ0BLU5z94u7yFiLPZf 2o1sI1j5SdhhIc/wlgtGczIx/l0tJAZn0a6FqTp82UN+dgawcOzRs5ThT5qND7t4w/vThK ny4FVtQ1JlvTk0nJCuglvHa7lMU1Cw8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-128-gQACcqVIMfqsFuIdIzMO6A-1; Mon, 19 Dec 2022 03:53:05 -0500 X-MC-Unique: gQACcqVIMfqsFuIdIzMO6A-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 82B9E8030CF; Mon, 19 Dec 2022 08:53:05 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4BD00492B00; Mon, 19 Dec 2022 08:53:05 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EB00A1800393; Mon, 19 Dec 2022 09:53:03 +0100 (CET) Date: Mon, 19 Dec 2022 09:53:03 +0100 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , "Justen, Jordan L" , Ard Biesheuvel , Oliver Steffen , Pawel Polawski Subject: Re: [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning Message-ID: <20221219085303.gzqitjjjex3mauve@sirius.home.kraxel.org> References: <20221216101134.2201546-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 17, 2022 at 03:10:25AM +0000, Yao, Jiewen wrote: > Hi Gerd > I would like to clarify a couple of things: > > 1) "Using these builds with writable flash is not secure." > > Whenever we say "secure" or "not secure", we need align the threat model at first. > What component is trusted? Which is not trusted? Who is adversary? With which capability? Under which attack scenario? Well, the OS can write directly to flash, bypassing the firmware. It can update secure boot efi variables without the firmware enforcing the usual restrictions (KEK signature being required for db/dbx updates etc). > If we are going to say something like that, we need a full description. Just saying: "not secure" is not enough. We simply don't get the protection secure boot is supposed to provide. > 3) What is definition of "stateless secure boot configuration" ? > What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or something else? "stateless" means we don't have persistent efi variables. > Then why not call it as simple as "secure boot without SMM" ? > I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless". Secure boot in OVMF in 2022-08 + older requires flash memory as efi variables storage and SMM mode support to enforce all efi variable updates being handled by the firmware. Starting with 2022-11 it is also possible to use secure boot without SNN mode and with the emulated variable store in RAM. Min added that for IntelTdx. The firmware can't enforce variable update rules in that case, but that is compensated by initializing the emulated variable store content with a pristine copy from ROM on each boot. So the OS can tamper with the efi variables, but it can't attack the system that way because any changes done are wiped on reset, before the firmware looks at those variables again when checking efi binary signatures. This also means any regular efi variable updates (like setting Boot* variables on install) are wiped on reset too. This is where the term "stateless" comes from. I don't see how "secure boot without SMM" is easier to understand than "stateless". It also is x64-specific. But the idea to give up variable persistence to get secure boot support without processor support for a separate privilege level can work on other platforms too. ArmVirt for example could get secure boot support that way without depending on TrustZone. > 4) What is the purpose of "Log a warning" ? > Is that to tell people, DON'T DO IT? Yes. Maybe it's better to refuse to boot in that case, a warning in a logfile is easily missed. In 2022-08 and older the world is relatively simple. We have three possible build configurations (1) SECURE_BOOT_ENABLE=FALSE SMM_REQUIRE=FALSE Build without secure boot support. (2) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=TRUE Build with secure boot support, secure. (3) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=FALSE Build with secure boot support, not secure. Linux Distributions typically provide builds for (1) and (2), so (3) existing isn't much of a problem in practice because people typically don't compile edk2 by themself. In 2022-11 the (3) case is splitted into two: (3a) build being used with ROM (or r/o flash): -> this is the new "stateless secure boot" mode. (3b) build being used with writable flash: -> insecure configuration. Now the same build can be secure or not depending on runtime configuration. So this patch tries to catch (3b) with a runtime check. take care, Gerd