xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: Regressed XSA-286, was [xen-unstable test] 161917: regressions - FAIL
Date: Wed, 16 Jun 2021 16:43:00 +0100	[thread overview]
Message-ID: <637ff3c7-afeb-aae4-0f1d-5ae168e01e01@citrix.com> (raw)
In-Reply-To: <b57c2120-2f86-caa7-56ec-e215a7ad0529@suse.com>

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



  reply	other threads:[~2021-06-16 15:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13  3:56 osstest service owner
2021-05-13 20:15 ` Regressed XSA-286, was " Andrew Cooper
2021-05-17  8:43   ` Jan Beulich
2021-05-17 10:59     ` Jan Beulich
2021-06-16  8:48   ` Jan Beulich
2021-06-16 15:43     ` Andrew Cooper [this message]
2021-06-17 11:56       ` Jan Beulich
2021-06-17 13:05         ` Ian Jackson
2021-06-17 14:40           ` Jan Beulich
2021-06-17 14:49             ` Ian Jackson
2021-06-17 14:55               ` Jan Beulich
2021-06-28 12:35           ` Ping: " Jan Beulich
2021-06-17 21:26         ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=637ff3c7-afeb-aae4-0f1d-5ae168e01e01@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=committers@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: Regressed XSA-286, was [xen-unstable test] 161917: regressions - FAIL' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).