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=-9.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 D0F19C43461 for ; Wed, 16 Sep 2020 07:46:22 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 78D132080C for ; Wed, 16 Sep 2020 07:46:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="F4XBtoMr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78D132080C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kIS8d-00045o-CO; Wed, 16 Sep 2020 07:45:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kIS8c-00045j-5f for xen-devel@lists.xenproject.org; Wed, 16 Sep 2020 07:45:58 +0000 X-Inumbo-ID: af7a5de6-936e-4b0f-a2c2-0514355e3c04 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id af7a5de6-936e-4b0f-a2c2-0514355e3c04; Wed, 16 Sep 2020 07:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1600242355; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=FGd41tedmz6bIXZWa7IZrHKursLyzDsGm8JNTgBE5ws=; b=F4XBtoMrZnZhjPwpmFfMXeAQgKfvUYeOYFXydLxw8/BlxlbaCoEiH8lw /W+H+TvMz8lFaCxgFXtJ3N7h2guZdpvYcysFLiar8kWWy5gAmrZwVZyGs IL4xUYSGVy8kjIxdRixBCm8TIEH4Y4w+0+xlnHB5haWMF+BJOKfr2RfrV Q=; Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: o6g63Ro/FGl7e2cOryKhsRZBC8wsURA2lsFoHttam4pywsEZtZtwSCmM7rK7UXZHbOQqLpQXzb Sr3WsbM1zRPgu8PA+AMdOz99aw4+6nAaHV2s29zpArORkmPPeI9glj1+zBVJE9OwEBx6VvahWd MkAzLek7/7MChZ1YSN2Ktt13dAtGyNvSzs4bVGxEmPXlAOaPQzu6+fEDNnXaziThh7IEDQhwE6 CeN/njfsfv0EwfU4HzQapMhN5x8IJ8AN7rx7frc1MF8ZQJ3H53elntRIsxeG4o+QGaswJVoyBL 3Fo= X-SBRS: 2.7 X-MesageID: 27782711 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.76,432,1592884800"; d="scan'208";a="27782711" Date: Wed, 16 Sep 2020 09:45:44 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Trammell Hudson CC: , , , Subject: Re: [PATCH v4 4/4] efi: Do not use command line if secure boot is enabled. Message-ID: <20200916074544.GS753@Air-de-Roger> References: <20200914115013.814079-1-hudson@trmm.net> <20200914115013.814079-5-hudson@trmm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20200914115013.814079-5-hudson@trmm.net> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To FTLPEX02CL06.citrite.net (10.13.108.179) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Sep 14, 2020 at 07:50:13AM -0400, Trammell Hudson wrote: > If secure boot is enabled, the Xen command line arguments are ignored. > If a unified Xen image is used, then the bundled configuration, dom0 > kernel, and initrd are prefered over the ones listed in the config file. I understand that you must ignore the cfg option when using the bundled image, but is there then an alternative way for passing the basevideo and mapbs parameters? Or there's simply no way of doing so when using secure boot with a bundled image? > Unlike the shim based verification, the PE signature on a unified image > covers the all of the Xen+config+kernel+initrd modules linked into the Extra 'the'. > unified image. This also ensures that properly configured platforms > will measure the entire runtime into the TPM for unsealing secrets or > remote attestation. > > Signed-off-by: Trammell Hudson > --- > xen/common/efi/boot.c | 44 ++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 41 insertions(+), 3 deletions(-) > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 4b1fbc9643..e65c1f1a09 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -949,6 +949,39 @@ static void __init setup_efi_pci(void) > efi_bs->FreePool(handles); > } > > +/* > + * Logic should remain sync'ed with linux/arch/x86/xen/efi.c > + * Secure Boot is enabled iff 'SecureBoot' is set and the system is > + * not in Setup Mode. > + */ > +static bool __init efi_secure_boot(void) > +{ > + static const __initconst EFI_GUID global_guid = EFI_GLOBAL_VARIABLE; > + uint8_t secboot, setupmode; > + UINTN secboot_size = sizeof(secboot); > + UINTN setupmode_size = sizeof(setupmode); > + EFI_STATUS rc; > + > + rc = efi_rs->GetVariable(L"SecureBoot", (EFI_GUID *)&global_guid, > + NULL, &secboot_size, &secboot); > + if ( rc != EFI_SUCCESS ) > + return false; > + > + rc = efi_rs->GetVariable(L"SetupMode", (EFI_GUID *)&global_guid, > + NULL, &setupmode_size, &setupmode); > + if ( rc != EFI_SUCCESS ) > + return false; > + > + if ( secboot > 1) Nit: missing space before closing parentheses. > + { > + PrintStr(L"Invalid SecureBoot variable=0x"); > + DisplayUint(secboot, 2); Maybe better to use secboot_size * 2 here since you already have the size of the variable anyway? Thanks, Roger.