Re: Regressed XSA-286, was [xen-unstable test] 161917: regressions - FAIL

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/06/2021 09:48, Jan Beulich wrote:
> On 13.05.2021 22:15, Andrew Cooper wrote:
>> On 13/05/2021 04:56, osstest service owner wrote:
>>> flight 161917 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/161917/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-arm64-arm64-examine      8 reboot                   fail REGR. vs. 
>>> 161898
>>>  test-arm64-arm64-xl-thunderx  8 xen-boot                 fail REGR. vs. 
>>> 161898
>>>  test-arm64-arm64-xl-credit1   8 xen-boot                 fail REGR. vs. 
>>> 161898
>>>  test-arm64-arm64-xl-credit2   8 xen-boot                 fail REGR. vs. 
>>> 161898
>>>  test-arm64-arm64-xl           8 xen-boot                 fail REGR. vs. 
>>> 161898
>> I reported these on IRC, and Julien/Stefano have already committed a fix.
>>
>>> Tests which are failing intermittently (not blocking):
>>>  test-xtf-amd64-amd64-3 92 xtf/test-pv32pae-xsa-286 fail in 161909 pass in 
>>> 161917
>> While noticing the ARM issue above, I also spotted this one by chance. 
>> There are two issues.
>>
>> First, I have reverted bed7e6cad30 and edcfce55917.  The XTF test is
>> correct, and they really do reintroduce XSA-286.  It is a miracle of
>> timing that we don't need an XSA/CVE against Xen 4.15.
> As expressed at the time already, I view this reverting you did, without
> there being any emergency and without you having gathered any acks or
> allowed for objections, as overstepping your competencies. I did post a
> patch to the XTF test, which I believe is wrong, without having had any
> feedback there either. Unless I hear back by the end of this week with
> substantial arguments of why I am wrong (which would need to also cover
> the fact that an issue was found with 32-bit PAE only, in turn supporting
> my view on the overall state), I intend to revert your revert early next
> week.

It has frankly taken a while to formulate a civil reply.

I am very irritated that you have *twice* recently introduced security
vulnerabilities by bypassing my reviews/objections on patches.

At the time, I had to drop work on an in-progress security issue to
urgently investigate why we'd regressed upstream, and why OSSTest hadn't
blocked it.

I am more generally irritated that you are constantly breaking things
which GitlabCI can tell you is broken, and that I'm having to drop work
I'm supposed to be doing to unbreak them.

In the case of this revert specifically, I did get agreement on IRC
before reverting.


In your proposed edit to the XTF test, you say

  L3 entry updates aren't specified to take immediate effect in PAE mode:

but this is not accurate.  It's what the Intel SDM says, but is
contradicted by the AMD APM which states that this behaviour is not true
under NPT under any circumstance, nor is it true on native.

Furthermore, any 32bit PV guest knowing it is running on a 64bit Xen
(even from simply checking Xen >= 4.3) can rely on the relaxed
behaviour, irrespective of what the unwritten PV ABI might want to say
on the matter, due to knowing that it is running on Long mode paging as
opposed to legacy PAE paging.

If these two technical reasons aren't good enough, then consider the
manifestation of the issue itself.  XSA-286 is specifically about Xen
editing the wrong PTE, because of the use of linear pagetables, in light
of the guest not flushing the TLB.

If you were to remove linear pagetables from Xen, the issue
(do_mmu_update() edits the wrong PTE) would cease to manifest even on
legacy PAE paging, demonstrating that the problem is with Xen's actions,
not with the guests.

~Andrew