linux-kernel - Re: [PATCH v2 2/6] arm64: Move kill_cpu

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: <20151201152826.GA28370@leverpostej>
Date:	Tue, 1 Dec 2015 15:28:26 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	"Suzuki K. Poulose" <suzuki.poulose@....com>
Cc:	linux-arm-kernel@...ts.infradead.org, marc.zyngier@....com,
	linux-kernel@...r.kernel.org, will.deacon@....com,
	catalin.marinas@....com
Subject: Re: [PATCH v2 2/6] arm64: Move kill_cpu_early to smp.c

Hi Suzuki,

On Tue, Dec 01, 2015 at 03:12:07PM +0000, Suzuki K. Poulose wrote:
> This patch moves kill_cpu_early to smp.c, where it fits better.
> No functional changes, except for adding the necessary checks
> for CONFIG_HOTPLUG_CPU.

This is mostly a code move, and the comments below were true for the
original, too.

> +/*
> + * Kill the calling secondary CPU, early in bringup before it is turned
> + * online.
> + */
> +void kill_cpu_early(void)
> +{
> +	int cpu = smp_processor_id();
> +
> +	pr_crit("CPU%d: will not boot\n", cpu);
> +
> +	/* Mark this CPU absent */
> +	set_cpu_present(cpu, 0);
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +	/* Check if we can park ourselves */
> +	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
> +		cpu_ops[cpu]->cpu_die(cpu);
> +#endif

Is there no way we can synchronise against this from another CPU, to be
sure that this CPU is actually gone?

> +
> +	asm(
> +	"1:	wfe\n"
> +	"	wfi\n"
> +	"	b	1b");
> +}

This can be:

for (;;) {
	wfe();
	wfi();
}

Regardless of that, we now have a CPU stuck in the kernel, despite
beleiving it to be !present (and therefore !online).

This is problematic for anything where we need to offline or stop
secondary CPUs. For instance, we need to inhibit kexec here (as we will
also need to in case CPUs were stuck in the spinning due to spin-table).

Thanks,
Mark.
--
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/