https://sourceware.org/bugzilla/show_bug.cgi?id=34626
Bug ID: 34626
Summary: Use UD after indirect jump in PLT entries
Product: binutils
Version: 2.48 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
CC: fweimer at redhat dot com
Target Milestone: ---
Target: x86-64
Florian Weimer pointed out in
https://groups.google.com/g/x86-64-abi/c/S3UrBVe9l7U/m/kRpGLFilEAAJ
The IBT-enabled PLT stub currently looks like this:
0000000000000660 <fclose@plt>:
660: f3 0f 1e fa endbr64
664: ff 25 66 68 00 00 jmp *0x6866(%rip) # 6ed0 <fclose@GLIBC_2.2.5>
66a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
The regular PLT stub ends with a jump (it has direct audit support):
00000000000020c0 <fclose@plt>:
20c0: ff 25 e2 7d 00 00 jmp *0x7de2(%rip) # 9ea8 <fclose@GLIBC_2.2.5>
20c6: 68 09 00 00 00 push $0x9
20cb: e9 50 ff ff ff jmp 2020 <free@plt-0x10>
But the audit/lazy resolution stub also has a NOP after the indirect jump:
0000000000002020 <free@plt-0x10>:
2020: ff 35 2a 7e 00 00 push 0x7e2a(%rip) # 9e50 <error_at_line@@Base+0x7835>
2026: ff 25 2c 7e 00 00 jmp *0x7e2c(%rip) # 9e58 <error_at_line@@Base+0x783d>
202c: 0f 1f 40 00 nopl 0x0(%rax)
However, the Intel optimization manual says:
| Assembly/Compiler Coding Rule 13. (M impact, L generality) When
| indirect branches are present, try to put the most likely target of
| an indirect branch immediately following the indirect
| branch. Alternatively, if indirect branches are common but they
| cannot be predicted by branch prediction hardware, then follow the
| indirect branch with a UD2 instruction, which will stop the
| processor from decoding down the fall-through path.
So I believe these NOPs should better be UD2 instructions.
--
You are receiving this mail because:
You are on the CC list for the bug.
