linux-kernel - Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

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: <alpine.DEB.2.20.1610041628120.5049@nanos>
Date:   Tue, 4 Oct 2016 16:38:16 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Prarit Bhargava <prarit@...hat.com>
cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Len Brown <len.brown@...el.com>, Borislav Petkov <bp@...e.de>,
        Andi Kleen <ak@...ux.intel.com>, Jiri Olsa <jolsa@...hat.com>,
        Juergen Gross <jgross@...e.com>, dyoung@...hat.com,
        Eric Biederman <ebiederm@...ssion.com>,
        kexec@...ts.infradead.org
Subject: Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded
 CPUs

On Tue, 4 Oct 2016, Prarit Bhargava wrote:
> On 10/04/2016 06:58 AM, Thomas Gleixner wrote:
> > While it is the right thing to initialize the package map in that case, it
> > still papers over a robustness issue in the uncore code, which needs to be
> > fixed first.
> 
> I will include a separate patch with an error check for pkg == 0xffff in the
> uncore code.

0xffff? That won't help. The id returned is -1 if the entry is not
initialized. And aside of that just patching that particular place is not
helping as the uncore code and also rapl is relying on the package map
being populated.

So we need a sanity check in the initialization code which prevents any of
this being executed.
 
> >> +		if (!num_processors) {
> >> +			pr_warn("CPU 0 not enumerated in mptable or ACPI MADT\n");
> >> +			num_processors = 1;
> > 
> > And in this case we end up with the same problem, right?
> 
> It occurs to me that I over thought this: I was thinking that there might exist
> a pre-ACPI (or at least a system without an MADT) x86 system that wold boot such
> that num_processors = 0.  But in that case, the cpu should be listed in the
> mptables so the above should not happen.  I'll change that to a BUG().

No. That's the wrong thing to do. Think SMP kernel on UP machines ...

Thanks,

	tglx