Re: [PATCH 2 of 2] vpmu: Add the BTS extension

[Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>]

Am Dienstag 14 Februar 2012, 14:50:30 schrieb Jan Beulich:
> >>> On 14.02.12 at 15:30, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> > Am Dienstag 14 Februar 2012, 13:27:08 schrieb Jan Beulich:
> >> Plus enforcing the buffer requirements to avoid CPU deadlock
> >> (contiguous present pages, alignment). Failure to do so can hang the
> >> CPU, and hence would represent a DoS vulnerability.
> > 
> > I'm not sure what you mean here. Are you speaking about the DS buffer?
> > If yes, this is no problem, because the DS buffer addressm must be a domU
> > virtual address. The processor only writes data into the buffer, if the
> > domU is running so in the worst case the domU gets triggered a page fault
> > or what I testet a triple fault occurs and the domU gets rebootet.
> 
> This certainly can be CPU model dependent, but on raw hardware
> I know that not meeting the buffer constraints can hang (not triple
> fault, perhaps a live lock) a CPU. Therefore, unless you can prove
> this is impossible when running in VMX non-root, you will have to add
> provisions for this (and this was the major reason keeping me from
> trying to add DS support a year or two ago). At the very minimum
> the whole functionality would otherwise need to be disabled by
> default, and when enabled a prominent warning be issued (along
> the lines of that of sync_console).

Of course I can't prove anything.
While I experimented with this I couldn't find any statement in the cpu specs
about this buffer stuff and what the cpu does with wrong addresses. I found
that writing a non canonical address into the MSR_IA32_DS_AREA leads to a
general protection fault in the hypervisor. This was the cause for the check of
is_canonical_address(msr_content).
But with this check I tried different addresses, also wrong addresses within
the buffer and the hypervisor didn't crash anymore but the domU always failed
with the:
hvm.c:1141:d10 Triple fault on VCPU0 - invoking HVM system reset.
But of course there may be other critical pathes.

Currently we have the vpmu boot flag. So by default this is disabled.
The question is, should the BTS suff get an own flag or should we change the
vpmu flag to a string with multiple meanings? If the warning should be printed
only for the BTS stuff then an own BTS flag is needed.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html