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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 07/09/16 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.

The rowhammer test takes a long time; on the order of an hour or two.  I
don't think people would appreciate those kinds of boot times. ;-)

Additionally, the default version in the Google repo randomly corrupts
memory -- potentially including Xen memory.  And if you have ECC memory,
the result of an uncorrestable error is often a machine reboot.  So
there would be a risk that adding such a test on a vulnerable system
would cause Xen to always reboot; or worse, to boot but after having
corrupted its own data or text segments.

I've been playing around with it, but "unfortunately" both my test
machine and the machine under my desk have ECC RAM.  I ran the
double-sided rowhammer test for 3 hours yesterday on the machine under
my desk, and the Linux EDAC driver didn't report any errors corrected.
This could either be because no errors happened, or because the errors
weren't being reported to Linux.  If no errors happened, it could be
because I'm not vulnerable, or because the test doesn't work on my hardware.

So unfortunately, there are just too many unknowns at this point to give
useful advice, other than "ECC RAM is probably better than non-ECC RAM".

 -George

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