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] [day] [month] [year] [list]

Message-ID: <20250424140330.42007-1-xieyuanbin1@huawei.com>
Date: Thu, 24 Apr 2025 22:03:30 +0800
From: xieyuanbin1 <xieyuanbin1@...wei.com>
To: <linux@...linux.org.uk>
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>, <xieyuanbin1@...wei.com>
Subject: RE: [PATCH] ARM: spectre-v2: fix unstable cpu get

From: Xie Yuanbin <xieyuanbin1@...wei.com>

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

Your assumption is correct, and I agree with it.

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

I have never mentioned a test tool, and I agree with you.
The problem I mentioned before is possible illegal instruction and panic.

If we want to fix this problem without affecting performance,
can we add a new hook functions (in fsr-3level.c)?

I don't know much about the details of the ARM manual,
Are all user-mode access to kernel-mode addresses are `permission fault`
and common page faults (hot code) are `access flag fault`?
If so, we can add a new hook function to deal with `permission fault`
and set it in fsr-3level.c.
This means we fix the problem without adding a branch,
that there is no performance loss.

Otherwise, we can only add condition judgment before enabling irq,
which means that performance loss occurs. This is so sad. :(