| 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
| ||
|
Message-ID: <20250114175143.81438-23-vschneid@redhat.com>
Date: Tue, 14 Jan 2025 18:51:35 +0100
From: Valentin Schneider <vschneid@...hat.com>
To: linux-kernel@...r.kernel.org,
x86@...nel.org,
virtualization@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
loongarch@...ts.linux.dev,
linux-riscv@...ts.infradead.org,
linux-perf-users@...r.kernel.org,
xen-devel@...ts.xenproject.org,
kvm@...r.kernel.org,
linux-arch@...r.kernel.org,
rcu@...r.kernel.org,
linux-hardening@...r.kernel.org,
linux-mm@...ck.org,
linux-kselftest@...r.kernel.org,
bpf@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com
Cc: Juergen Gross <jgross@...e.com>,
Ajay Kaher <ajay.kaher@...adcom.com>,
Alexey Makhalov <alexey.amakhalov@...adcom.com>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <kernel@...0n.name>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Frederic Weisbecker <frederic@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Jason Baron <jbaron@...mai.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ard Biesheuvel <ardb@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>,
Boqun Feng <boqun.feng@...il.com>,
Uladzislau Rezki <urezki@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Zqiang <qiang.zhang1211@...il.com>,
Juri Lelli <juri.lelli@...hat.com>,
Clark Williams <williams@...hat.com>,
Yair Podemsky <ypodemsk@...hat.com>,
Tomas Glozar <tglozar@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ben Segall <bsegall@...gle.com>,
Mel Gorman <mgorman@...e.de>,
Kees Cook <kees@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
Shuah Khan <shuah@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>,
"Mike Rapoport (Microsoft)" <rppt@...nel.org>,
Samuel Holland <samuel.holland@...ive.com>,
Rong Xu <xur@...gle.com>,
Nicolas Saenz Julienne <nsaenzju@...hat.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Yosry Ahmed <yosryahmed@...gle.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
Jinghao Jia <jinghao7@...inois.edu>,
Luis Chamberlain <mcgrof@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Tiezhu Yang <yangtiezhu@...ngson.cn>
Subject: [PATCH v4 22/30] context_tracking: Exit CT_STATE_IDLE upon irq/nmi entry
ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
modify the actual CT state part context_tracking.state. This means that
upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
transition only happens in ct_idle_exit().
One can note that ct_nmi_enter() can only ever be entered with the CT state
as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in the
CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_exit().
Add/remove CT_STATE_IDLE from the context tracking state as needed in
ct_nmi_{enter, exit}().
Note that this leaves the following window where the CPU is executing code
in kernelspace, but the context tracking state is CT_STATE_IDLE:
~> IRQ
ct_nmi_enter()
state = state + CT_STATE_KERNEL - CT_STATE_IDLE
[...]
ct_nmi_exit()
state = state - CT_STATE_KERNEL + CT_STATE_IDLE
[...] /!\ CT_STATE_IDLE here while we're really in kernelspace! /!\
ct_cpuidle_exit()
state = state + CT_STATE_KERNEL - CT_STATE_IDLE
Signed-off-by: Valentin Schneider <vschneid@...hat.com>
---
kernel/context_tracking.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index a61498a8425e2..15f10ddec8cbe 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -236,7 +236,9 @@ void noinstr ct_nmi_exit(void)
instrumentation_end();
// RCU is watching here ...
- ct_kernel_exit_state(CT_RCU_WATCHING);
+ ct_kernel_exit_state(CT_RCU_WATCHING -
+ CT_STATE_KERNEL +
+ CT_STATE_IDLE);
// ... but is no longer watching here.
if (!in_nmi())
@@ -259,6 +261,7 @@ void noinstr ct_nmi_enter(void)
{
long incby = 2;
struct context_tracking *ct = this_cpu_ptr(&context_tracking);
+ int curr_state;
/* Complain about underflow. */
WARN_ON_ONCE(ct_nmi_nesting() < 0);
@@ -271,13 +274,26 @@ void noinstr ct_nmi_enter(void)
* to be in the outermost NMI handler that interrupted an RCU-idle
* period (observation due to Andy Lutomirski).
*/
- if (!rcu_is_watching_curr_cpu()) {
+ curr_state = raw_atomic_read(this_cpu_ptr(&context_tracking.state));
+ if (!(curr_state & CT_RCU_WATCHING)) {
if (!in_nmi())
rcu_task_enter();
+ /*
+ * RCU isn't watching, so we're one of
+ * CT_STATE_IDLE
+ * CT_STATE_USER
+ * CT_STATE_GUEST
+ * guest/user entry is handled by ct_user_enter(), so this has
+ * to be idle entry.
+ */
+ WARN_ON_ONCE((curr_state & CT_STATE_MASK) != CT_STATE_IDLE);
+
// RCU is not watching here ...
- ct_kernel_enter_state(CT_RCU_WATCHING);
+ ct_kernel_enter_state(CT_RCU_WATCHING +
+ CT_STATE_KERNEL -
+ CT_STATE_IDLE);
// ... but is watching here.
instrumentation_begin();
--
2.43.0
Powered by blists - more mailing lists