linux-kernel - Re: [tip:x86/bsp-hotplug] 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] [day] [month] [year] [list]

Message-ID: <52824AD8.8000607@zytor.com>
Date:	Tue, 12 Nov 2013 07:35:52 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
CC:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, hpa@...ux.intel.com,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/bsp-hotplug] x86, apic: Disable BSP if boot cpu is AP

On 11/12/2013 02:20 AM, HATAYAMA Daisuke wrote:
> 
> Thanks for pointing out that. I think the first two issues has already been
> fixed in v3 version. I've just posted v5 version a little time ago.

OK, I see now.  It looks like it was radically changed, so the branch in
the -tip tree is completely stale.

> BTW,
> I changed the basic design at v4 where we specify the initial APIC ID of
> the
> processor we want to disable in the kdump 2nd kernel from the the 1st
> kernel
> through newly introduced disable_cpu_apicid kernel parameter; it might be
> similar to the idea you described in the patch description of tip tree.

> I don't know the third issue. Could you explain what kind of things can
> happen on clustered system? Only IA32_APIC_BASE MSR is no longer trusted? Or are
> there other things we can possibly no longer trust?

On a clustered system, the CPU APICIDs will duplicate, as only a
hardware-specific method can obtain the cluster-wide ID.  That is why we
have struct apic.get_apic_id().

IA32_APIC_BASE_MSR is another matter... it doesn't even exist on older
hardware.  It might be as simple as if IA32_APIC_BASE_MSR doesn't exist
we ignore this whole mechanism (this applies to P5 and earlier, but also
modern derivatives like Quark) but we can't blindly touch this register
as it might trap.  At the very least it needs to be rdmsr_safe().

> Also, could you explain what you suggest to deal with the issue in more
> detail?

I think the only thing we can do is to record in the first kernel on
which CPU we were booted on.  Then there is no need to look at the BSP
flag in APIC_BASE_MSR at all or anything similar.

	-hpa

--
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/