linux-kernel - Re: [PATCH] x86/ioperm: add new paravirt function update_io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b0f33786-79b1-f8ee-24ae-ce9f9f4791af@suse.com>
Date:   Wed, 19 Feb 2020 06:35:16 +0100
From:   Jürgen Groß <jgross@...e.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        xen-devel@...ts.xenproject.org, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org
Cc:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        "VMware, Inc." <pv-drivers@...are.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] x86/ioperm: add new paravirt function update_io_bitmap

On 18.02.20 22:03, Thomas Gleixner wrote:
> Juergen Gross <jgross@...e.com> writes:
>> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
>> ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
>>
>> Unfortunately this broke Xen PV domains using that syscall as there
>> is currently no I/O bitmap support in PV domains.
>>
>> Add I/O bitmap support via a new paravirt function update_io_bitmap
>> which Xen PV domains can use to update their I/O bitmaps via a
>> hypercall.
>>
>> Fixes: 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() as well")
>> Reported-by: Jan Beulich <jbeulich@...e.com>
>> Cc: <stable@...r.kernel.org> # 5.5
>> Signed-off-by: Juergen Gross <jgross@...e.com>
>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
>> Tested-by: Jan Beulich <jbeulich@...e.com>
> 
> Duh, sorry about that and thanks for fixing it.
> 
> BTW, why isn't stuff like this not catched during next or at least
> before the final release? Is nothing running CI on upstream with all
> that XEN muck active?

This problem showed up by not being able to start the X server (probably
not the freshest one) in dom0 on a moderate aged AMD system.

Our CI tests tend do be more text console based for dom0.


Juergen