[kernel-xen] Fwd: [Xen-announce] Xen Security Advisory 154 (CVE-2016-2270) - x86: inconsistent cachability flags on guest mappings

[Steven Haigh]

This is the crux of my issue.

'some' may cover a specific chipset, a specific cpu, or something else. 
So, do we impose a performance degradation on *every* system running the 
code for an issue with a specific chipset?

I'm not aware of any proof of concept code to cause problems. I also 
notice the word 'might' in:

"A malicious guest administrator might be able to cause a reboot,
denying service to the entire host."

I also note:
"The vulnerability depends on the system response to mapping the same
memory with different cacheability.  On some systems this is harmless;
on others, depending on CPU and chipset, it may be fatal."

Even if the hardware / systems in use could be listed - or even a test 
for if the hardware has this problem were available, it would assist in 
coming to a conclusion.

I also note:
"Only x86 guests given control over some physical device can trigger
this vulnerability."

This makes me wonder if ONLY systems that have PCI Passthrough enabled 
have this issue.

On the lack of all this information, I really wasn't comfortable pushing 
the patches without being able to qualify the scope further. However, 
now the embargo is over, its a good time to start public discussion.

On 2016-02-18 12:22, Glenn Enright wrote:
> Where the notice says "performance regression with this patch on
> some systems", its a shame that the actual server configuration was
> not described in more detail, at least having that would provide some
> baseline for discussion and potentially help build a knowledge base of
> systems affected.
> 
> A concern of course is that the use of "some" in various places on the
> notice is so vague, and might actually mean "most/all the machines we
> tested".
> 
> It would also be nice to see details on the notice of a POC for the
> issue, presumably the security team had a test case. Else how else
> could they properly patch for it? I'm wondering why that has not been
> published as well, any idea if such is available now embargo is
> lifted?
> 
> Regards, Glenn
> http://ri.mu - Startups start here.
> Hosting. DNS. Web Programming. Email. Backups. Monitoring.
> 
> On 18/02/16 14:07, Steven Haigh wrote:
>> Hi all,
>> 
>> I'd like to forward this for discussion to the list - as you'll notice
>> that I have only patched XSA-170 released today.
>> 
>> The patch below is somewhat interesting - as a workaround is presented
>> by a new option (not available in previous patch versions) to restore
>> the performance regression involved with this fix. The problem is, 
>> with
>> this option, you reintroduce the security issue that the patch 
>> resolves.
>> 
>> As such, it leaves us with two scenarios:
>> 1) Apply the patch and take the performance hit (not sure of the scale
>> of this hit or what it affects) - even if your hardware is not
>> vulnerable; or
>> 2) Use the command line option which makes this patch moot.
>> 
>> I wasn't able to canvas this list for opinions on this before the
>> embargo ended - but am interested to gather peoples feedback after
>> analysis.
>> 
>> My concerns are that there is not enough quantifiable information to 
>> be
>> able to easily determine a way forward. There is not enough 
>> information
>> to make me comfortable as to what hardware is affected, what degree 
>> the
>> of performance loss is.
>> 
>> Am happy to get feedback on other peoples thoughts on this issue.
>> 
> _______________________________________________
> kernel-xen mailing list
> kernel-xen at lists.wireless.org.au
> https://lists.wireless.org.au/mailman/listinfo/kernel-xen

-- 
Steven Haigh

Email: netwiz at crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897