linux-kernel - Re: [PATCH 0/2] x86, apic: Disable BSP if boot cpu is AP

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: <8738ps131z.fsf@xmission.com>
Date:	Thu, 29 Aug 2013 16:37:44 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>, vgoyal@...hat.com,
	akpm@...ux-foundation.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, jingbai.ma@...com
Subject: Re: [PATCH 0/2] x86, apic: Disable BSP if boot cpu is AP

"H. Peter Anvin" <hpa@...ux.intel.com> writes:

> On 08/29/2013 02:27 AM, HATAYAMA Daisuke wrote:
>> This is the patch series to address the issue that kdump 2nd kernel
>> now fails to wake up multiple CPUs.
>
> Please explain the "now" in the above sentence.  Is this a regression?
> If so, what is its fimpact?

This is not a regression.

>  Is this something that needs to go into 3.11
> as a post-rc7 change, which means it better be hyper-critical?

No.  This is something that does not need to go into 3.11.

This situation is people who run machines of unreasonable size really
would like to use multiple cpus when generating crash dumps.  A
practical problem with that desire is that sending a (startup? init? I
forget which) IPI to a processor with the BSP flag sent triggers that
processor to load code from 0xfffffff0 instead of the vector specified
in the IPI.  At which point the processor which jumped to 0xfffffff0 and
is running BIOS code does not call into the kernel so never comes up
which is unfortunate, and worse almost always triggers a soft reset by
writing hardware registers.

Which means the practical way to avoid this sort of thing is not to send
init/startup IPIs to processors with the BSP bit set.  Which MPtables
and ACPI tables should denote as the boot processor.

In a previous attack on this problem we explored if it was possible to
clear the BSP bit and be able to use all processors but that does not
work.  I think it was actually your suggestion that we just skip the
BSP.

Anyway this long simmering issue has raised it's head again and we have
iron-clad evidence that the only thing people can do is avoid the
problem so this is a patchset to allow people who wind up in a
situtation where they are not booting on the bootstrap processor to to
avoid problems, and use as many of their other processors as possible.

Which should make people with boxes of unusual size happy.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/