2023-12-07 19:49:38

by Thomas Gleixner

[permalink] [raw]
Subject: [patch 0/2] x86/alternatives: Prevent crash in NOP optimizer

The following series addresses the regression report from Paul on behalf of
the yocto project. It turns out that the recent changes to alternatives
opened a race window where interrupts are enabled and NOPs are optimized in
place. An interrupt hitting into the modification will observe inconsistent
text and crash and burn.

A 32bit QEMU crashes w/o these fixes reliably within about 50 boot
attempts. With the fix applied it survived close to 600 attempts by
now.

Thanks to Paul for providing all the information!

Thanks,

tglx



2023-12-08 08:36:16

by Paul Gortmaker

[permalink] [raw]
Subject: Re: [patch 0/2] x86/alternatives: Prevent crash in NOP optimizer

[[patch 0/2] x86/alternatives: Prevent crash in NOP optimizer] On 07/12/2023 (Thu 20:49) Thomas Gleixner wrote:

> The following series addresses the regression report from Paul on behalf of
> the yocto project. It turns out that the recent changes to alternatives
> opened a race window where interrupts are enabled and NOPs are optimized in
> place. An interrupt hitting into the modification will observe inconsistent
> text and crash and burn.
>
> A 32bit QEMU crashes w/o these fixes reliably within about 50 boot
> attempts. With the fix applied it survived close to 600 attempts by
> now.

I can confirm that - since I was already set up for it, I let it run
overnight for about 1250 attempts. With an average of one in 200 that I
was seeing before, I should have had around six fails. Didn't see one.

> Thanks to Paul for providing all the information!

On behalf of Richard and myself, thanks for the complex fix.

Paul.
--

>
> Thanks,
>
> tglx
>
>

2023-12-15 09:12:19

by Peter Zijlstra

[permalink] [raw]
Subject: Re: [patch 0/2] x86/alternatives: Prevent crash in NOP optimizer

On Thu, Dec 07, 2023 at 08:49:22PM +0100, Thomas Gleixner wrote:
> The following series addresses the regression report from Paul on behalf of
> the yocto project. It turns out that the recent changes to alternatives
> opened a race window where interrupts are enabled and NOPs are optimized in
> place. An interrupt hitting into the modification will observe inconsistent
> text and crash and burn.
>
> A 32bit QEMU crashes w/o these fixes reliably within about 50 boot
> attempts. With the fix applied it survived close to 600 attempts by
> now.
>
> Thanks to Paul for providing all the information!

Urgh and D'0h.

Acked-by: Peter Zijlstra (Intel) <[email protected]>