Re: Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[George Dunlap <george.dunlap@citrix.com>]

On 07/09/16 16:33, Ian Jackson wrote:
> 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.

The attack described in [4] relies on the fact that the attacker knows
the mfn of the L2 pagetables being used by the hardware.  Using shadows
for the L2+ pagetables would thwart that particular attack, and
shouldn't in theory cause too much overhead.

But that would only thwart a particular attack.  Other attacks are
certain to develop; we can only strongly advise all our users that if
they expect to have determined adversaries inside their guests, that
they should make every effort to use RAM which is not vulnerable to
rowhammer attacks.

 -George

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