linux-kernel - Re: 32 bit qemu regression from v6.5 tip pull [6c480f222128 x86/alternative: Rewrite optimize

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]

Date:   Mon, 30 Oct 2023 12:44:50 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Richard Purdie <richard.purdie@...uxfoundation.org>
Cc:     Paul Gortmaker <paul.gortmaker@...driver.com>,
        Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: 32 bit qemu regression from v6.5 tip pull [6c480f222128
 x86/alternative: Rewrite optimize_nops() some]

On Mon, Oct 30, 2023 at 10:55:26AM +0000, Richard Purdie wrote:
> On Mon, 2023-10-30 at 09:26 +0100, Peter Zijlstra wrote:
> > On Sun, Oct 29, 2023 at 02:41:46PM -0400, Paul Gortmaker wrote:
> > > The TL;DR is that the Yocto folks encountered a regression in their
> > > automated QA tests (after a move from v6.4 --> v6.5) where non-KVM
> > > enabled boot tests on 32 bit x86 would (with ~2% frequency) splat with:
> > 
> > You're sure you're not running into this here:
> > 
> >   https://lkml.kernel.org/r/20230706170537.95959-1-richard.henderson@linaro.org
> > 
> > ?
> 
> We're using qemu 8.1.0. Whilst I will get us updated to 8.1.2 and see
> if that helps, I think those commits are in 8.1.0:
> 
> $ git show cb62bd15e14e304617d250158b77d0deb032f03
> commit cb62bd15e14e304617d250158b77d0deb032f032
> Author: Richard Henderson <richard.henderson@...aro.org>
> Date:   Thu Jul 6 08:45:13 2023 +0100
> 
>     accel/tcg: Split out cpu_exec_longjmp_cleanup
> [...]
> $ git tag --contains cb62bd15e14e304617d250158b77d0deb032f03
> v8.1.0
> v8.1.0-rc0
> v8.1.0-rc1
> v8.1.0-rc2
> v8.1.0-rc3
> v8.1.0-rc4
> v8.1.1
> v8.1.2
> 
> Similarly for:
> 
> commit deba78709ae8ce103e2248413857747f804cd1ef
> Author: Richard Henderson <richard.henderson@...aro.org>
> Date:   Thu Jul 6 17:55:48 2023 +0100
> 
>     accel/tcg: Always lock pages before translation
> 
> and
> 
> commit ad17868eb162a5466d8ad43e5ccb428776403308
> Author: Richard Henderson <richard.henderson@...aro.org>
> Date:   Wed Jul 26 12:58:08 2023 -0700
> 
>     accel/tcg: Clear tcg_ctx->gen_tb on buffer overflow
> [...]
>     Fixes: deba78709ae8 ("accel/tcg: Always lock pages before translation")
> 
> Both of which are also in 8.1.0.
> 
> Is there any other patch related to those we might be missing?

Not sure -- afaik that was it.

Thomas was looking at this and wondered if something like the below
would help?

---
 arch/x86/kernel/alternative.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 73be3931e4f0..fd44739828f7 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -1685,8 +1685,8 @@ void __init_or_module text_poke_early(void *addr, const void *opcode,
 	} else {
 		local_irq_save(flags);
 		memcpy(addr, opcode, len);
-		local_irq_restore(flags);
 		sync_core();
+		local_irq_restore(flags);
 
 		/*
 		 * Could also do a CLFLUSH here to speed up CPU recovery; but