From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.3877.1591902459486737021 for ; Thu, 11 Jun 2020 12:07:39 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B26201FB; Thu, 11 Jun 2020 12:07:37 -0700 (PDT) Received: from [192.168.1.69] (unknown [10.37.8.184]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ECAD03F66F; Thu, 11 Jun 2020 12:07:36 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH v3 14/14] OvmfPkg: use generic QEMU image loader for secure boot enabled builds To: Laszlo Ersek , devel@edk2.groups.io Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= References: <20200305134607.20125-1-ard.biesheuvel@linaro.org> <20200305134607.20125-15-ard.biesheuvel@linaro.org> <5243a882-187f-6ca4-2450-a6c958a934e3@redhat.com> <7d7d1cbc-d1ca-c3dd-c2ac-00084d79decf@redhat.com> <20eb271e-ac27-c097-e933-2d2273dfb4d5@arm.com> <85097379-850e-ece2-13e7-eefeb30d12ed@redhat.com> <56eff0cf-b76e-be82-db0e-b6a44a7f1908@arm.com> From: "Ard Biesheuvel" Message-ID: Date: Thu, 11 Jun 2020 21:07:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 6/11/20 8:13 PM, Laszlo Ersek wrote: > On 06/11/20 17:05, Ard Biesheuvel wrote: ... >> >> If we can ensure that the only bootable images that are exempt from the >> secure boot checks are ones that were provided directly by the host >> userspace, then I think their position is not unreasonable, given that >> the guest is at its mercy anyway. >> > > Thanks. > > So... reverting this patch would only affect the behavior of the > QemuLoadKernelImage() API, and that API only consumes fw_cfg. Fw_cfg is > under the control of the host userspace (QEMU implements the fw_cfg > "platform hardware). Does that satisfy your condition ("provided > directly by the host userspace"), or are you referring to any "farther" > origin on the host side, from where the fw_cfg content is originally taken? > No, that is fine. I am just slightly unhappy that any code that happily circumvents the normal secure/measured boot flow entirely is even present in the image. > IOW would you involve in this decision the question where on the network > the kernel image is downloaded from (on the host), for example? (I > wouldn't -- for me, the fact that fw_cfg is technically controlled by > QEMU is enough.) > Yes. > FWIW I've reverted the patch downstream (a deadline forced my hand > before we could conclude this upstream thread, and the use cases that > had regressed are considered important), but I really dislike that > divergence from upstream. I'd like to eliminate that downstream patch > when we rebase to a subsequent stable tag. > Since we're on list: Acked-by: Ard Biesheuvel on a revert of ced77332cab626f35fbdb36630be27303d289d79. Merge it whenever you see fit.