[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 16 Jun 2021 16:43:00 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0mZ1lbsU7yf9CgkDPRlTbyZCvhu9rRsQqF5qrUkQ2t8=; b=c3WqLsTSa1mojrHxL1C4JTAL01DbhJul38QqS91r5bsshZenkYnU1xolwNOl+TnkRPo64blZBWh4fdYW2mfYGQ1PhYyHacShdgLI+qVgJx1YjAQu39DuIk3e2iN150GIcLIS+3NMavX5Ob1Lb6kdHk4UI6pz/QD7e9vXDymqznENUoqO3t75You8ndSECcOtrgd+In/ENv1SexOrWDlwqZb0eZqzY0pkWbloCq3+Xy13JWqKgkRjvJn3ahsR07uNGI3FRYRLE6uZLHhA/jX/gfwzBCodxhCMoQyZpOpsV4S1HF2sJTHoI1wro0PPVcmHbaLHCj9xwPfWnSqBGem4kw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AoUFc12oDpbmTTca4EPdGqL4TCjVhGVmFC0UxqQiTFQaluJPCP8QuPs6rU7MYDhdok5rH+1LEgobAIYqXqRVaANZFD8hBJlAH9KMJ28MqLVrgy9QTXqyVBj0kTnQGI3+F+Hiw+nuqIY9oJabShsFlCcyz0zhPTp1NwsxNINViuueMNfdD/0pPntqj+vWSdcfFgDoI+Jt+ZDUWEB+O4meZ7yD8gr40gC2bUoH/D7OJrXBQc9cgWcVduabFGb8su6dAp5rFCj5y6G1/nMVrCxOOX0DB5ufhDKyN3HQyYNIUydbyIdPJDBOH4fGX882x+w7yXXPF82dlg7eEUvCgg5/Gg==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 16 Jun 2021 15:43:17 +0000
  • Ironport-hdrordr: A9a23:GAGdA60LDssbaF2gf3nyqgqjBEgkLtp133Aq2lEZdPU0SKGlfg 6V/MjztCWE7Ar5PUtLpTnuAsa9qB/nm6KdgrNhWItKPjOW21dARbsKheffKlXbcBEWndQtt5 uIHZIeNDXxZ2IK8PoT4mODYqodKA/sytHWuQ/cpU0dMz2Dc8tbnmBE4p7wKDwMeOFBb6BJcq a01458iBeLX28YVci/DmltZZm4mzWa/KiWGCLvHnQcmXGzsQ8=
  • Ironport-sdr: ohFkRoilwqXOXeg3BAoXD1Peau5PjDIjWrRgQv6k4UwpzIYxnZn7If1RN1AwJlkKlztv6C9p9c FQCqlfd6YIyfwOvKooaqGE8QKMRlCFuWnzFQBh2HVEVAbMLCXOjlskGPObFR5o6QF2dEFf3iw/ AC0Hp/6BeN7bVkPGEP2I8OkN3Nmjr7ySdzhEQdKC0qzStYUKTPsnlrgdnoGnvbYagRC3Q9z/+U 1LK2VTBa8Iciawz4/8sq4+EHfjVauNQxFhhRd6MZ6t51nmb7NP3zpiwRUb3jllWfUx9sTtmtlp YKI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.