Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash

From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash
Date: Wed, 9 Mar 2016 15:06:05 +0100	[thread overview]
Message-ID: <56E02DCD.5060008@redhat.com> (raw)
In-Reply-To: <56DECE5F.6000207@redhat.com>

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
> 