linux-kernel - Re: [PATCH] Updates to Xen hypercall preemption

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: <0ff85b95-f4c7-445c-b0e0-7368c182ee0b@app.fastmail.com>
Date:   Wed, 21 Jun 2023 16:42:44 -0700
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Per Bilse" <Per.Bilse@...rix.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Juergen Gross" <jgross@...e.com>,
        "Stefano Stabellini" <sstabellini@...nel.org>,
        "Oleksandr Tyshchenko" <oleksandr_tyshchenko@...m.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "moderated list:XEN HYPERVISOR INTERFACE" 
        <xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH] Updates to Xen hypercall preemption



On Wed, Jun 21, 2023, at 12:05 PM, Per Bilse wrote:
> On 6/21/2023 5:27 PM, Andy Lutomirski wrote:
>> This code is a horrible mess, with and without your patches.  I think that, if this were new, there's no way it would make it in to the kernel.
>
> Hi Andy, and many thanks for your frank assessments.  Generally, this
> is indeed somewhat old code, first introduced in 2015 by way of commit
> fdfd811ddde3.  There's more information in the notes to that, and it's
> maybe worth noting that we're not trying to introduce anything new,
> merely fix what various commits since then have broken.
>
>> I propose one of two rather radical changes:
>> 
>> 1. (preferred) Just delete all of it and make support for dom0 require either full or dynamic preempt, and make a dynamic preempt kernel booting as dom0 run as full preempt.
>
> Personally I think that's a good idea; a machine so limited in resources
> that a fully preemptible dom0 kernel would be a problem wouldn't work as
> a Xen server anyway.  Having said that, what to do about this isn't
> really in my hands; the issues came to light because the kernel for
> Citrix's XenServer product is being upgraded, and it was considered in
> everybody's interest to upstream the fixes.  I'll see what I can do.

This isn’t actually a resource thing. It’s a distro thing.

Historically, full preempt was a config option only, and distros, for whatever reason, often shipped kernels with full preempt disabled.  (There we probably decent reasons. There may still be decent reasons.). And Xen needed to work on these kernels.  Hence the mess.

But Linux recently gained the ability to build a kernel that, by default, is not full preempt but can be switched *at boot or runtime* to full preempt. And distros should ship *that* (or a kernel that does have full preempt by default).

So let’s just make Xen PV dom0 depend on this. It wasn’t an option a couple years ago. Now it is.

>
> Best,
>
>    -- Per