From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adekr-0002Zz-4f for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:06:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adekl-0003tu-7t for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:06:25 -0500 References: <1455288361-30117-1-git-send-email-peter.maydell@linaro.org> <56DD9C58.7050306@redhat.com> <56DEBF6A.6070809@redhat.com> <56DEC234.70907@redhat.com> <56DEC860.1060707@redhat.com> <56DECE5F.6000207@redhat.com> From: Laszlo Ersek Message-ID: <56E02DCD.5060008@redhat.com> Date: Wed, 9 Mar 2016 15:06:05 +0100 MIME-Version: 1.0 In-Reply-To: <56DECE5F.6000207@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Ard Biesheuvel Cc: Peter Maydell , qemu-arm , QEMU Developers , Markus Armbruster , "Michael S. Tsirkin" On 03/08/16 14:06, Paolo Bonzini wrote: > On 08/03/2016 13:50, Ard Biesheuvel wrote: >> Note that, for KVM, it is unlikely that we will ever support all of >> this inside the guest. It makes *much* more sense to lock down the >> emulated flash, and implement the UEFI Runtime Services using a thin >> layer in UEFI that hooks up to interfaces exposed to the guest by >> QEMU. > > Well, it makes a bit less sense if the SMM code is already there for you > to use. :) More seriously, implementing secure boot on x86 KVM was > "just" a matter of reading the architecture manual and chipset > datasheets, and implementing what they said. Likewise, the firmware > work can reuse a large part of the work done for bare-metal hardware. > Laszlo would kill me for saying this, :) but in terms of sheer SLOC his > platform enablement patches were dwarfed by the SMM code that Intel > contributed. The SMM code in turn is _exactly_ the same on bare-metal > and virt. Your statement about the SLOC proportions is correct. And, while I could try to depict (again) the challenges that regardless surfaced in the platform enablement, this is not the right forum, so I'll save it. :) However: despite reusing the core SMM code identically in the guest, there is at least one stark behavioral difference: in QEMU the SMI is raised only on the processor that triggers it. This exercises paths in the core SMM code where processors have to count down timeouts and bring each other in, and these busy loops are very visible to an interactive user in certain circumstances. For example, Windows installers seem to be absolutely crazy about massaging UEFI variables -- the rotating animation rather crawls than rotates for a minute. I traced KVM just the other day while the installer was in this phase, and 2 VCPUs together produced about 30-50 "(entering|leaving) SMM" messages per second. Laszlo > Designing good PV interfaces is hard, designing secure PV interfaces is > harder; reading a spec is easy. To me, the only reason to do it in PV > interfaces is that the hardware doesn't allow virtualization of EL3. > > If the hardware makes you jump through extra hoops, sometimes it's > necessary, sometimes it's not. If it's not, rationalizing it is bad. I > cannot think of a good reason for hardware not to let you virtualize > hypervisor or secure mode, or to force the hypervisor to use two-level > page translation. > > Paolo >