diff options
author | Borislav Petkov <bp@suse.de> | 2021-06-01 18:51:22 +0300 |
---|---|---|
committer | Borislav Petkov <bp@suse.de> | 2021-06-03 17:33:09 +0300 |
commit | 2b31e8ed96b260ce2c22bd62ecbb9458399e3b62 (patch) | |
tree | c47f14cbd904623f9836dc57f5f110e2790c64a0 /arch/x86/realmode/init.c | |
parent | 9bfecd05833918526cc7357d55e393393440c5fa (diff) | |
download | linux-2b31e8ed96b260ce2c22bd62ecbb9458399e3b62.tar.xz |
x86/alternative: Optimize single-byte NOPs at an arbitrary position
Up until now the assumption was that an alternative patching site would
have some instructions at the beginning and trailing single-byte NOPs
(0x90) padding. Therefore, the patching machinery would go and optimize
those single-byte NOPs into longer ones.
However, this assumption is broken on 32-bit when code like
hv_do_hypercall() in hyperv_init() would use the ratpoline speculation
killer CALL_NOSPEC. The 32-bit version of that macro would align certain
insns to 16 bytes, leading to the compiler issuing a one or more
single-byte NOPs, depending on the holes it needs to fill for alignment.
That would lead to the warning in optimize_nops() to fire:
------------[ cut here ]------------
Not a NOP at 0xc27fb598
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:211 optimize_nops.isra.13
due to that function verifying whether all of the following bytes really
are single-byte NOPs.
Therefore, carve out the NOP padding into a separate function and call
it for each NOP range beginning with a single-byte NOP.
Fixes: 23c1ad538f4f ("x86/alternatives: Optimize optimize_nops()")
Reported-by: Richard Narron <richard@aaazen.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213301
Link: https://lkml.kernel.org/r/20210601212125.17145-1-bp@alien8.de
Diffstat (limited to 'arch/x86/realmode/init.c')
0 files changed, 0 insertions, 0 deletions