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: <333138f8-9fbe-be5b-d125-12c9d3ed3eda@citrix.com>
Date:   Wed, 21 Jun 2023 19:05:41 +0000
From:   Per Bilse <Per.Bilse@...rix.com>
To:     Andy Lutomirski <luto@...nel.org>,
        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 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.

Best,

   -- Per