From nobody Fri May 17 16:38:51 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1659608216; cv=none; d=zohomail.com; s=zohoarc; b=dmYlv0IjnolT0XY/3oQ7jez8P9QClhdP5mxL3UV69BIBME46di4Q7h3HkOo36Uq5eMQSMQIvgbGThhz+/Hq6fwU98crgBAlKVN6eL3LvpSxOybnK7cDw8BMFcV28mnxnEf5P56oh6I3lQwp6gJyXfaaLmQ+JE2KQB5gHXJZ4E/0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1659608216; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=U+IFgI7VliEgXk7VS4ft5PuT7SKbsxu8ns3VeuJN/1w=; b=Vz8Ogw2UxjPzG5/ixpAo6KmS2MG3sTIoJrxvpNVhcc9hRxi+XhKp6cxfpW/xMZwZzMD4b48pKWnwgmTcukfpjPnAe1FdOwNsJejyy6J48sv1YcUkPW+V1AXX36LV0MrhW0ZW26+tv2d5JiTtcHbKkE1vlWg8RMWIlunG83J9aEA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.zohomail.com with SMTPS id 1659608216459586.3131535722964; Thu, 4 Aug 2022 03:16:56 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-84-d_-V7WhNPPmkSn1_Nur7PA-1; Thu, 04 Aug 2022 06:16:50 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8BA531C1977C; Thu, 4 Aug 2022 10:16:48 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 76E702166B2B; Thu, 4 Aug 2022 10:16:48 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 2E5E81946A53; Thu, 4 Aug 2022 10:16:48 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A410C1946A52 for ; Thu, 4 Aug 2022 10:16:46 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 94E614010E37; Thu, 4 Aug 2022 10:16:46 +0000 (UTC) Received: from harajuku.usersys.redhat.com.homenet.telecomitalia.it (unknown [10.40.194.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2175F4010FA2 for ; Thu, 4 Aug 2022 10:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659608214; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=U+IFgI7VliEgXk7VS4ft5PuT7SKbsxu8ns3VeuJN/1w=; b=df/YJcbV5bJjMHTOCTG1VweUCGMXrhqkjyAUHjZZR3MN48Dv0x2Bu3X5XrE5aqS8FAM1wd b+RrgI0nTTvcFbEX7W9ACtg0YtXpds4W+ZCVXZappLyPvTSh8E3+k1vlaHfSihbD119RoS TxhueR9bQAfdFFbYLAlq3Qd1hh9sKVo= X-MC-Unique: d_-V7WhNPPmkSn1_Nur7PA-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 1/2] kbase: Always explicitly enable secure-boot firmware feature Date: Thu, 4 Aug 2022 12:16:41 +0200 Message-Id: <20220804101642.52262-2-abologna@redhat.com> In-Reply-To: <20220804101642.52262-1-abologna@redhat.com> References: <20220804101642.52262-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1659608218534100001 Content-Type: text/plain; charset="utf-8"; x-default="true" It should be enough to enable or disable the enrolled-keys feature to control whether Secure Boot is enforced, but there's a slight complication: many distro packages for edk2 include, in addition to general purpose firmware images, builds that are targeting the Confidential Computing use case. For those, the firmware descriptor will not advertise the enrolled-keys feature, which will technically make them suitable for satisfying a configuration such as In practice, users will expect the general purpose build to be used in this case. Explicitly asking for the secure-boot feature to be enabled achieves that result at the cost of some slight additional verbosity. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrang=C3=A9 --- docs/kbase/secureboot.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/kbase/secureboot.rst b/docs/kbase/secureboot.rst index 8f151c1f2a..5fa59ad5e2 100644 --- a/docs/kbase/secureboot.rst +++ b/docs/kbase/secureboot.rst @@ -14,6 +14,7 @@ ask for Secure Boot to be enabled with =20 + @@ -24,6 +25,7 @@ and for it to be disabled with =20 + @@ -44,6 +46,7 @@ snippet: + --=20 2.37.1 From nobody Fri May 17 16:38:51 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1659608220; cv=none; d=zohomail.com; s=zohoarc; b=TWkSMP6/2NOlrwZsXFcuSPOY0KA1EM6y6C5SjzByxriMNfMMBq7vVPK6k0Jqk6gL3FfdjUykBTnPnfcBbKbEqOgd0WdS6M4klS2/3qIqDVHD1qfyJsMN3ks+ID0HtJQz2rUdl2BR73akUHrscByby7Wuvut3INcLPyYIBmiDxy0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1659608220; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=4SlsaLNvcqshsv72oHokPNqS5gsjfxqLXgeP9YyGvRI=; b=b0WyyBbGhbgT+VpyD8lKbIzis4GLFziW52GM94EKjqxpNi2EAJ92kPfzHWzQ0j0peS9bRtNxajrggtDEsp+ASL9SzbObXRIItL48mB0ifEVVuqfWQWKQt/VwnERTjfDjyQGI0JlwIysKANOE7RaoqoHB2g+mpKN7AStsIaK57no= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.zohomail.com with SMTPS id 1659608220498884.1079860069019; Thu, 4 Aug 2022 03:17:00 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-0M-Z6lvuPwWS3QweT0D3pw-1; Thu, 04 Aug 2022 06:16:51 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 10AAA3C0D87B; Thu, 4 Aug 2022 10:16:49 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id F195B2026D4C; Thu, 4 Aug 2022 10:16:48 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7F3401946A5E; Thu, 4 Aug 2022 10:16:48 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7893C1946A52 for ; Thu, 4 Aug 2022 10:16:47 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 6BEA140C124A; Thu, 4 Aug 2022 10:16:47 +0000 (UTC) Received: from harajuku.usersys.redhat.com.homenet.telecomitalia.it (unknown [10.40.194.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ED2EF40C1288 for ; Thu, 4 Aug 2022 10:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659608219; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=4SlsaLNvcqshsv72oHokPNqS5gsjfxqLXgeP9YyGvRI=; b=dGRQSiUfObfeCzGd4uL2pKFJHX3QNbJoUf3FrkcktjQLPBn/4k0nGk//ndsiynQnZ2s875 cZRMPt1MEw1GVj+pmkqmz2MtSj1V4iZG5wYAgDY4j7RP9RNRnWkfcEJOo3gW+06bZN6Rtj 3FEiOUvXXk7HTY3O+0NZ1cuJ3Gz+UDs= X-MC-Unique: 0M-Z6lvuPwWS3QweT0D3pw-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH v2 2/2] kbase: Document how to disable Secure Boot entirely Date: Thu, 4 Aug 2022 12:16:42 +0200 Message-Id: <20220804101642.52262-3-abologna@redhat.com> In-Reply-To: <20220804101642.52262-1-abologna@redhat.com> References: <20220804101642.52262-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1659608222563100001 Content-Type: text/plain; charset="utf-8"; x-default="true" In most cases, disabling the secure-boot or the enrolled-keys firmware feature will achieve the same result: allowing an unsigned operating system to run. Right now we're only documenting the latter configuration. Add the former as well, and explain the difference between the two. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrang=C3=A9 --- docs/kbase/secureboot.rst | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/kbase/secureboot.rst b/docs/kbase/secureboot.rst index 5fa59ad5e2..4340454a7b 100644 --- a/docs/kbase/secureboot.rst +++ b/docs/kbase/secureboot.rst @@ -19,7 +19,17 @@ ask for Secure Boot to be enabled with =20 -and for it to be disabled with +and for it to be disabled with either + +:: + + + + + + + +or =20 :: =20 @@ -30,8 +40,10 @@ and for it to be disabled with =20 -These configuration will cause unsigned guest operating systems to -be rejected and allowed respectively. +The first configuration will cause unsigned guest operating systems +to be rejected, while the remaining two will allow running them. See +below for a more detailed explanation of how each knob affects the +firmware selection process. =20 =20 Older libvirt versions @@ -103,3 +115,16 @@ The opposite configuration, where the feature is expli= citly disabled, will result in no keys being present in the NVRAM file. Unable to verify signatures, the firmware will allow even unsigned operating systems to run. + +If running unsigned code is desired, it's also possible to ask for +the ``secure-boot`` feature to be disabled, which will cause libvirt +to pick a build of EDKII that doesn't have Secure Boot support at +all. + +The main difference between using a build of EDKII that has Secure +Boot support but without keys enrolled and one that doesn't have +Secure Boot support at all is that, with the former, you could enroll +your own keys and securely run an operating system that you've built +and signed yourself. If you are only planning to run existing, +off-the-shelf operating system images, then the two configurations +are functionally equivalent. --=20 2.37.1