From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.36035.1590429752388329338 for ; Mon, 25 May 2020 11:02:33 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aVpQUxiQ; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590429751; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9cs8msMfybJ11gzuoWD6XvUIlNQ7bZhr61V1Yg2Wm3M=; b=aVpQUxiQX7Vs2ztmPj5FAPCLySNMuuNVa+K1DymcDel1AephMDQh/Di0MnXRCEMTKBsklI VBwOl2eJ5+pZJxMAnkI0+CpHYHx92huhsehluLsWGnY7ga38JxaPXeS64skKGihuMjrFlS Rm6pv3Jou4b+CFVKuXi5qncri9EsxAA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-283-Axp3ZeevNvO52p2tt3mxpg-1; Mon, 25 May 2020 14:02:22 -0400 X-MC-Unique: Axp3ZeevNvO52p2tt3mxpg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3BAAF107ACF4; Mon, 25 May 2020 18:02:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-168.ams2.redhat.com [10.36.114.168]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0EDCF1BCBE; Mon, 25 May 2020 18:02:19 +0000 (UTC) Subject: Re: [EXTERNAL] Re: [edk2-devel] [PATCH v3 05/14] OvmfPkg: Add VariablePolicy engine to OvmfPkg platform To: Bret Barkelew , "devel@edk2.groups.io" , "michael.kubacki@outlook.com" Cc: Jordan Justen , Ard Biesheuvel References: <20200521224331.15616-1-michael.kubacki@outlook.com> <2e4a7b3c-a732-48bd-27b2-d3aef4b1690a@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Mon, 25 May 2020 20:02:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Bret, On 05/23/20 00:35, Bret Barkelew wrote: > 'Maybe you entirely missed my message that I posted in response to > version 2 of this specific patch (i.e. you may have fully missed the > message I link at the top). That could be the case because I mentioned > "OvmfXen.dsc" under the v2 blurb as well.' > > Yup. That's the one. Saw this request, but not the patch feedback. > Will address in the next version. Thanks. > You want the PCD dropped just for Xen? No; I'd like it to be removed from all ArmVirtPkg and OvmfPkg DSC files. > > I would posit that dropping it for all of OVMF would negate the > ability to use the unittest test to confirm the functionality in CI, > which is something I would like to light up in future revisions, so I > would need to hear the argument against it. I spelled it out in the message you missed: http://mid.mail-archive.com/a0e0e3d4-6712-078a-4d95-29408109b0b0@redhat.com https://edk2.groups.io/g/devel/message/59271 To summarize briefly, the wiki page relating to this feature makes the valid general argument that the PCD default should be secure. And that applies specifically to the ArmVirtPkg and OvmfPkg platforms as well; their upstream DSC files too should be as production-ready as possible. Regarding the CI tests, I addressed them in the same message. I named two options. One, we can build OVMF (specifically in the CI system too) with the "--pcd" build option, to override the PCD from the DEC default. Two, if we want just one binary, and override the PCD at boot time (rather than at build time), we can do that as well, with a bit more work -- make the PCD dynamic-access, and put a recently introduced OvmfPkg and ArmVirtPkg feature (from TianoCore#2681) to use, for letting users change the dynamic boolean PCD from the QEMU command line. Hm... I can in fact quote it for you: > Now, I realize that people might want to set this PCD to TRUE in OVMF, > for testing various things. Maybe the unit tests / functional tests > introduced in this series even *depend* on the PCD being TRUE (I can't > tell, I haven't checked). That's OK; for accommodating that, we have > two options: > > (2a) build OVMF with the appropriate --pcd=... switch passed to > "build", > > (2b) for controlling the PCD dynamically (on the QEMU command line): > > - the PCD would have permit the dynamic access method in the DEC file, > > - the modules consuming the PCD would have to do so in their entry > point functions / library constructors, and use the cached copy > thenceforth, > > - the OVMF DSC files would have to get a dynamic default (value > FALSE), > > - and OVMF would need another NULL class library for setting the PCD > from fw_cfg. Please refer to > for details on > that. Thanks Laszlo