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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security 
Vulnerability Process"):
> A few years ago it was discovered that much of the RAM shipped in our
> computers contains flaws which allow "leakage" across rows; effectively
> allowing programs to use access to one bit of memory to flip bits in
> other parts of memory to which they have been specifically denied
> access.  This has attack on faulty hardware has been dubbed "rowhammer" 
> [1].
...

> From my perspective, there are a number of differing goals we are trying 
> to achieve with the process
...
> b) If already public (or at disclosure time), ensure that our users have 
>    all the information to make the right choices

This is my concern.

From my POV XSAs are a convenient established format and process.

However, I don't think this necessarily needs to be dealt with by
issuing an actual XSA, particularly if there are other reasons for
doing things differently.  We could brief our users by writing some
other kind of message, perhaps posted on xen-announce.

Indeed several aspects of the XSA process are not really applicable.

One main reason for issuing an XSA for an ordinary software bug is
that it allows the issue, and its fix, to be tracked in a standardised
way.  CVEs perform the same function, with a more general scope.

But, we would not expect to get a CVE for what really amounts to a
hardware quality issue.  And where there can be little useful way of
avoiding a hardware bug by adding workarounds to the software
(specifically, in our case, by modifying Xen), there is no need to
track whether any particular codebase has the mitigation.

So there is little benefit in assigning a number.

Unlike with software bugs, there is also relatively little benefit in
having rowhammer listed on a web page alongside software bugs.

The XSA advisory template format does not lend itself well to this
issue, as I found when I tried to write a draft.  While does have the
benefit of being in a format which is familiar to users, user response
will have to be quite different.  And the level of uncertainty and
hardware-dependence means that the usual questions such as `Impact'
and `Vulnerable systems' have unsatisfactory non-answers, in such a
bulletin.

We did issue XSA-3 for a mitigationless hardware design problem.  But
that was in a very different environment: the XSA process was not as
formally established as it is now, and the publicity implications were
different.

> 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).

> b) Whether the technique described in [3] is serious on big iron with 
>    different core/cache properties compared to some of the machines this 
>    was tested on

This is a big question.

> c) Whether there is any mitigation that we can develop, if necessary

AIUI there is little to be done.  But, I look forward to being proven
wrong.

Ian.

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