linux-kernel - Re: [PATCH] ARM: spectre-v2: fix unstable cpu get

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: <aApBpnDcq2KNkfAs@shell.armlinux.org.uk>
Date: Thu, 24 Apr 2025 14:50:30 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: xieyuanbin1 <xieyuanbin1@...wei.com>
Cc: liaohua4@...wei.com, lincheng8@...wei.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	nixiaoming@...wei.com, sfr@...b.auug.org.au, wangbing6@...wei.com,
	wangfangpeng1@...wei.com, will@...nel.org
Subject: Re: [PATCH] ARM: spectre-v2: fix unstable cpu get

On Thu, Apr 24, 2025 at 09:31:33PM +0800, xieyuanbin1 wrote:
> I've actually thought about a similar problem. In areas other than put_cpu/get_cpu, tasks may be scheduled to other CPUs, this cpu actually does not execute the spectre code. 

My point is that if harden_branch_predictor() has been called from a
context where we are preemptible, then we _could_ end up running on a
different CPU to the one that we need to take action.

Consider your test program running on CPU 1 which requires fixup. It
takes a fault, and before we enter harden_branch_predictor(), we end
up being migrated to CPU 0, but doesn't require a switch of the MM.
Let's say we then disable preemption and then call
harden_branch_predictor(), and then restore the preemption state.
The thread then gets migrated back to CPU 1. Again, no switch of
the MM.

At this point, the mitigation has been completely bypassed.

IMHO, better to be noisy about this event (and it is only a kernel
warning) than to be silent about it and let userspace get away with
bypassing the mitigation.

I don't care if this disrupts test tooling. The trade off between
test tooling having a problem and a silent data leak through this
channel... the answer is pretty obvious that the test tooling
failing is less important than having a silent data leak.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!