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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

What's the conclusion here -- are you inclined to say that we shouldn't
issue an XSA, but perhaps do some other sort of announcement?

 -George


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