linux-kernel - Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer

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: <Zbpylz6ep3skWF9d@windriver.com>
Date: Wed, 31 Jan 2024 11:17:27 -0500
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: Borislav Petkov <bp@...en8.de>
Cc: X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a
 temporary buffer

[[PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer] On 30/01/2024 (Tue 11:59) Borislav Petkov wrote:

> From: "Borislav Petkov (AMD)" <bp@...en8.de>
> 
> Hi,
> 
> here's a small set which sprang out from my reacting to the fact that
> NOPs optimization in the alternatives code needs to happen on
> a temporary buffer like the other alternative operations - not in-place
> and cause all kinds of fun.
> 
> The result is this, which makes the alternatives code simpler and it is
> a net win, size-wise:
> 
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> 
> Constructive feedback is always welcome!

So, I figured I would set up the same reproducer, on the same machine;
build and test a known broken NOP rewrite kernel like v6.5.0 to confirm
I could still reproduce the boot fail in approximately 2% of runs.  And
then move to testing this series.

Well, much to my annoyance my plan broke down at step one.  After about
three hours and over 400 runs, I didn't get a single fail. I still had a
known broken build from the original reporting in October of v6.5.7, so
I let that run for over 300 iterations, and also didn't get any
failures.

I have to assume that even though I'm using the same host, same scripts,
that because I was testing on Yocto master, other things have changed
since October - maybe binutils, qemu, the runqemu script,  ...  In
theory, I could try and reset Yocto back to October-ish but that is
probably of diminishing returns.  And I can't unwind the host machine
distro updates that have happened since October.

With hindsight and knowledge of what the issue was and how narrow the
window was to trigger it, I guess this shouldn't be a surprise.

So as a "next best" effort, I let this rc1-alt-v2 branch run overnight,
and after over 2200 iterations, I didn't get any boot fails.

Paul.
--

> 
> Thx.
> 
> Borislav Petkov (AMD) (4):
>   x86/alternatives: Use a temporary buffer when optimizing NOPs
>   x86/alternatives: Get rid of __optimize_nops()
>   x86/alternatives: Optimize optimize_nops()
>   x86/alternatives: Sort local vars in apply_alternatives()
> 
>  arch/x86/kernel/alternative.c | 122 ++++++++++++++--------------------
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> -- 
> 2.43.0
>