summaryrefslogtreecommitdiff
path: root/arch/x86/realmode/init.c
diff options
context:
space:
mode:
authorBorislav Petkov <bp@suse.de>2021-06-01 18:51:22 +0300
committerBorislav Petkov <bp@suse.de>2021-06-03 17:33:09 +0300
commit2b31e8ed96b260ce2c22bd62ecbb9458399e3b62 (patch)
treec47f14cbd904623f9836dc57f5f110e2790c64a0 /arch/x86/realmode/init.c
parent9bfecd05833918526cc7357d55e393393440c5fa (diff)
downloadlinux-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