From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2448B2095B062 for ; Tue, 10 Oct 2017 10:26:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 21D64267E0; Tue, 10 Oct 2017 17:29:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 21D64267E0 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-87.rdu2.redhat.com [10.10.120.87]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF703779D6; Tue, 10 Oct 2017 17:29:44 +0000 (UTC) To: "Yao, Jiewen" , "Long, Qin" Cc: Brijesh Singh , "edk2-devel@lists.01.org" , "Justen, Jordan L" , Tom Lendacky , "Zhang, Chao B" References: <20171005201642.122619-1-brijesh.singh@amd.com> <74D8A39837DF1E4DA445A8C0B3885C503A9D7CF9@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <604c8fb0-cedc-fc8f-78e9-1ca5b6ecd06d@redhat.com> Date: Tue, 10 Oct 2017 19:29:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9D7CF9@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 10 Oct 2017 17:29:47 +0000 (UTC) Subject: Re: [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 17:26:19 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/10/17 15:46, Yao, Jiewen wrote: > I am OK on this patch. > > Reviewed-by: Jiewen.yao@intel.com Thanks! (Thanks to Qin as well!) > BTW: Do you also need update PcdRemovableMediaImageVerificationPolicy and PcdFixedMediaImageVerificationPolicy? No, not at this time -- in OvmfPkg we are fine with the 0x04 defaults for those PCDs, and don't intend to change them at all (either dynamically or via a different fixed-at-build default). The option ROM verification policy is special, because in a virt guest environment, the host environment is trusted by default, and the option ROMs come from the host environment. For this reason we originally overrode the relevant PCD with value 0x00 -- ALWAYS_EXECUTE. However, in SEV guests, the host environment is no longer trusted, and we should restore the 0x04 policy for option ROMs. Given that SEV is detected dynamically in OVMF, we need to massage the PCD dynamically too. Do you think that all of these PCDs should be declared similarly (i.e. that their declarations should permit the exact same set of storage types, for symmetry)? If so, do you prefer a follow-up patch for the DEC file, or a v3 of this set? Thanks! Laszlo > > > Thank you > Yao Jiewen > > > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Tuesday, October 10, 2017 7:28 PM > To: Long, Qin ; Yao, Jiewen > Cc: Brijesh Singh ; edk2-devel@lists.01.org; Justen, Jordan L ; Tom Lendacky ; Zhang, Chao B > Subject: Re: [edk2] [PATCH v2 1/2] SecurityPkg: make PcdOptionRomImageVerificationPolicy dynamic > > Jiewen, Qin, > > can you guys perhaps help with reviewing this patch? (The second patch > in the series is for OvmfPkg, and it depends on this one.) > > Thanks! > Laszlo > > On 10/05/17 22:16, Brijesh Singh wrote: >> By default the image verification policy for option ROM images is 0x4 >> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit: >> >> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot >> >> set it to 0x0 (ALWAYS_EXECUTE). This is fine because typically option >> ROMs comes from host-side and most of the time cloud provider (i.e >> hypervisor) have full access over a guest anyway. But when secure boot >> is enabled, we would like to deny the execution of option ROM when >> SEV is active. Having dynamic Pcd will give us flexibility to set the >> security policy at the runtime. >> >> Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728 >> Cc: Chao Zhang > >> Cc: Jordan Justen > >> Cc: Laszlo Ersek > >> Cc: Tom Lendacky > >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Brijesh Singh > >> --- >> >> Changes since v1: >> * Add Contributed-under tag >> >> SecurityPkg/SecurityPkg.dec | 24 ++++++++++---------- >> 1 file changed, 12 insertions(+), 12 deletions(-) >> >> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec >> index 01bff01ed50a..4e32d172d7d9 100644 >> --- a/SecurityPkg/SecurityPkg.dec >> +++ b/SecurityPkg/SecurityPkg.dec >> @@ -230,18 +230,6 @@ [Ppis] >> # >> >> [PcdsFixedAtBuild, PcdsPatchableInModule] >> - ## Image verification policy for OptionRom. Only following values are valid:

>> - # NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification and has been removed.
>> - # 0x00000000 Always trust the image.
>> - # 0x00000001 Never trust the image.
>> - # 0x00000002 Allow execution when there is security violation.
>> - # 0x00000003 Defer execution when there is security violation.
>> - # 0x00000004 Deny execution when there is security violation.
>> - # 0x00000005 Query user when there is security violation.
>> - # @Prompt Set policy for the image from OptionRom. >> - # @ValidRange 0x80000001 | 0x00000000 - 0x00000005 >> - gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x00000001 >> - >> ## Image verification policy for removable media which includes CD-ROM, Floppy, USB and network. >> # Only following values are valid:

>> # NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification and has been removed.
>> @@ -304,6 +292,18 @@ [PcdsFixedAtBuild, PcdsPatchableInModule] >> gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeSubClassTpmDevice|0x010D0000|UINT32|0x00000007 >> >> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] >> + ## Image verification policy for OptionRom. Only following values are valid:

>> + # NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification and has been removed.
>> + # 0x00000000 Always trust the image.
>> + # 0x00000001 Never trust the image.
>> + # 0x00000002 Allow execution when there is security violation.
>> + # 0x00000003 Defer execution when there is security violation.
>> + # 0x00000004 Deny execution when there is security violation.
>> + # 0x00000005 Query user when there is security violation.
>> + # @Prompt Set policy for the image from OptionRom. >> + # @ValidRange 0x80000001 | 0x00000000 - 0x00000005 >> + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04|UINT32|0x00000001 >> + >> ## Indicates the presence or absence of the platform operator during firmware booting. >> # If platform operator is not physical presence during boot. TPM will be locked and the TPM commands >> # that required operator physical presence can not run.

>>