Re: Xen Security Advisory 9 (CVE-2012-2934) - PV guest host DoS (AMD erratum #121)

[John Haxby <john.haxby () oracle com>]

On 15 Jun 2012, at 19:09, Florian Weimer wrote:

> * Giles Coochey:
>
> > On 14/06/2012 19:20, Florian Weimer wrote:
> > > * Xen org security team:
> > >
> > > > There is no software fix for this issue. The workaround suggested by
> > > > AMD in erratum #121 cannot be applied to Xen since the relevant address
> > > > is under guest control.
> > > >
> > > > Applying the patch will cause Xen to detect vulnerable systems and
> > > > refuse to boot.
> > > This response puzzles me.  Isn't this changing a potential denial of
> > > service (a para-virtualized guest could attempt an exploit) to a
> > > definite one (the system won't boot)?  Why is this a good idea?
> > It ensures that the user of the system is aware of the risks.
> >
> > This position will only occur when the patch to the vulnerability is
> > applied (i.e. during an out of service upgrade). The admins of the
> > system should always read the release notes to patches and upgrades - 
> > otherwise they wouldn't know what else might be broken, deprecated.
>
> Sure, but why refuse to boot?  Wouldn't it be sufficient to refuse
> creating DomUs, and still create Dom0?  (Perhaps this suggestion
> doesn't make any sense—I'm not familiar with Xen.)


It still makes sense.   There's no easy mechanism to let the hypervisor pass the do-not-create-domU message to dom0 so 
that the person creating the guest will find out.   There's also a logical problem: dom0 is itself a PV guest.

The admin can take preventative action to disable untrusted PV guests and stopping the system booting is definitely the 
best way of attracting attention without having potentially difficult to diagnose problems.

jch