Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/09/2016 22:02, Stefano Stabellini wrote:
> On Wed, 7 Sep 2016, Meng Xu wrote:
>> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
>> <sstabellini@xxxxxxxxxx> wrote:
>>> On Wed, 7 Sep 2016, Ian Jackson wrote:
>>>>> Technical
>>>>> =========
>>>>> On the technical front, it would be good to understand whether
>>>>> a) This is a real threat and whether thus, we as a community need to
>>>>>    take action
>>>> It is unclear what action the Xen upstream community can usefully
>>>> take, other than providing users with information.
>>>>
>>>> But, users with deployments on actual hardware ought to try to find
>>>> out whether they are vulnerable.  If they are then they could seek
>>>> replacement non-faulty hardware from their vendor, or take unpleasant
>>>> migitation measures (like switching to HVM, perhaps).
>>> How difficult is to check for it?
>>>
>>> Is there a simple test, maybe a little executable, that users could use
>>> to find out whether their ram is vulnerable? That would be extremely
>>> valuable.
>> Google does have a github repo to do the rowhammer test:
>> https://github.com/google/rowhammer-test
> Nice! It would be good to document this in a Xen Project document
> somewhere.
>
> The code is small enough that we could even consider pulling it in Xen
> and running it at boot time (obviously it would be a kconfig option to
> compile and a xen command line option to run the test). In case of
> failure we could WARN the sysadmin and refuse to continue.

-10 for any code in the hypervisor.  That is a knee-jerk reaction.  By
the same logic, we should also embed memtest and run that during boot.

Documentation, and making a test easy to run is of course fine, but
noone will compile it in or use it in production.  In the best case, it
comes back quickly and identifies that you can't run untrusted guests,
and in the worse case runs forever.

It is very unfortunate that the very design and intention of the x86 PV
ABI makes it easier for most attackers than a typical user/kernel
interaction.  Hindsight is great, but there is no possible way that a
group of PHD students 15 years ago developing a mutually-cooperative
method of virtualisation could have predicted that in this modern day
and age, commercial DRAM is pushed too close to the limit to function
correctly in all cases software can provoke.

That said, there are both software and hardware mitigations which can be
used.  ECC RAM is a good start, and anyone running a production system
without it has already lost.  There is TRR as an optional DRAM mechanism
which I can see becoming de-facto standard (and likely non-optional in
DDR5).  More intellegent placement of guest memory could prevent it
performing rowhammer on anything but itself, and the proposed option to
move PV guests into an HVM stub container resolves the physical
information leakage which makes rowhammer particularly easy for PV guests.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel