On Fri, Sep 29, 2017 at 02:48:45PM -0500, Richard Relph wrote:
On 9/29/17 2:34 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 02:06:10PM -0500, Richard Relph wrote:
> > Whether the "BIOS" is a "static shim" as Michael suggests,
or a full BIOS,
> > or even a BIOS+kernel+initrd is really not too significant. What is
> > significant is that the GO has a basis for trusting all code that is
> > imported in to their VM by the CP. And that NONE of the code provided by the
> > CP is "unknown" and unauditable by the GO. If the CP has a way to
inject
> > code unknown to the GO in to the guest VM, the trust model is broken and
> > both GO and CP suffer the consequences.
>
> Absolutely.
>
> > When the CP needs to update the BIOS image, they will have to inform the GO
> > and allow the GO to establish trust in the CP's new BIOS image somehow.
>
> This GO update on every BIOS change is imho is not a workable model. You
> want something like checking the BIOS signature instead. And since
> hardware is all hash based, you need the shim to do it in software.
A BIOS "signed" by the CP doesn't meet the security requirement. It is
code
that is "unknown" to the GO.
The (legitimate) CP does NOT want to be in that position of trust. If they
are, then some government somewhere is going to insist that they sign a BIOS
that allows the government to spy on the GO's VMs, and steal secrets from
it. Or some hacker admin will do it "for fun".
How often do large public CPs really change their BIOSes? My sense is that
large public CPs prefer stability over "latest and greatest".
It is hard to generalize, but from a RHEL POV, we typically do major updates
of the virt stack every ~6 months, and these will include BIOS updates. So if
a cloud vendor is following the RHEL update stream actively that's the kind
of cadence you'd expect.
The gotcha would come if there were out-of-band security updates for BIOS
which caused it to be updated before the 6 month window. Fortunately I've
not see these happen often, so I don't think its a fatal problem.
IOW, I tend to agree with you that this is not really a blocking problem to
the use of SEV in cloud.
And, perhaps more importantly, if a CP are able to sell a "more
secure" VM,
one that justifies a higher price per vCPU hour, wouldn't that warrant some
changes in the "insecure" model being used today?
Yes.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|