linux-kernel - Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical

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]

Date:   Thu, 20 Apr 2017 18:04:14 +0100
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
CC:     Prarit Bhargava <prarit@...hat.com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, <xen-devel@...ts.xenproject.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>
Subject: Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer
 __max_logical_packages limit

On 20/04/17 16:06, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead of 4.
>
> This wastes quite a bit of memory for the per-node arrays. Luckily most
> are just pointer arrays, but still, wasting 140*8 bytes for each of
> them.
>
>> this should be safe and cover all
>> possible cases. Alternatively, we may think about eliminating the concept
>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>> total_cpus where we currently use topology_max_packages().
>>
>> The issue could've been solved in Xen too I guess. CPUID returning
>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>> all logical packages of the guest.
> This is getting ludicrous. Xen is plain broken, and instead of fixing
> it, you propose to somehow deal with its obviously crack induced
> behaviour :-(

Xen is (and has been forever) plain broken in this specific regard. 
Fixing CPUID handling for guests has taken me 18 months and ~80 patches
so far, and it still isn't complete.

However, Linux needs to be able to function on existing production
systems (which is every instance of Xen currently running).

Linux shouldn't BUG() because something provided by the firmware looks
wonky.  This is conceptually no different from finding junk the APCI tables.

(I fully agree that we shouldn't have got to this state, but we are 12
years too late in this respect.)

~Andrew