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

Borislav Petkov posted 4 patches 1 year, 10 months ago
There is a newer version of this series
arch/x86/kernel/alternative.c | 122 ++++++++++++++--------------------
1 file changed, 50 insertions(+), 72 deletions(-)
[PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer
Posted by Borislav Petkov 1 year, 10 months ago
From: "Borislav Petkov (AMD)" <bp@alien8.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!

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
Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer
Posted by Paul Gortmaker 1 year, 10 months ago
[[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@alien8.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
>
Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer
Posted by Borislav Petkov 1 year, 10 months ago
On Wed, Jan 31, 2024 at 11:17:27AM -0500, Paul Gortmaker wrote:
> 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.

Thanks a lot!

As mentioned on IRC yesterday, the important thing is that this doesn't
break any of your guests. And that is good enough.

Much appreciated, thanks again!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette