On Fri, Jan 22, 2021 at 1:17 PM Sami Tolvanen <samitolva...@google.com> wrote: > > Hi Josh, > > On Fri, Jan 22, 2021 at 7:42 AM Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > > On Thu, Jan 21, 2021 at 11:38:54PM +0100, Sedat Dilek wrote: > > > On Thu, Jan 21, 2021 at 10:29 PM Josh Poimboeuf <jpoim...@redhat.com> > > > wrote: > > > > > > > > v2: > > > > - fix commit description for why xen hypervisor page contents don't > > > > matter [Juergen] > > > > - annotate indirect jumps as safe instead of converting them to > > > > retpolines [Andrew, Juergen] > > > > - drop patch 1 - fake jumps no longer exist > > > > - add acks > > > > > > > > Based on tip/objtool/core. > > > > > > > > > > > > Add support for proper vmlinux.o validation, which will be needed for > > > > Sami's upcoming x86 LTO set. (And vmlinux validation is the future for > > > > objtool anyway, for other reasons.) > > > > > > > > This isn't 100% done -- most notably, crypto still needs to be supported > > > > -- but I think this gets us most of the way there. > > > > > > > > This can also be found at > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > > > > objtool-vmlinux > > > > > > > > > > Should this be s/objtool-vmlinux/objtool-vmlinux-v2 ? > > > > Indeed: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > > objtool-vmlinux-v2 > > I tested v2 on top of the LTO tree and with allyesconfig + relevant > crypto configs disabled, and I only see the warnings I reported > earlier. > > I also tested this on top of the CFI tree and with LTO+CFI enabled, I > can reproduce the segfault Sedat reported in the previous thread. This > happens because find_unsuffixed_func is called with a NULL sym in > read_relocs: > > Program received signal SIGSEGV, Segmentation fault. > find_unsuffixed_func (elf=elf@entry=0x7ffff55a5010, sym=0x0, > suffix=0x416cbf ".cfi_jt", func=func@entry=0x7fffffffd5f0) at > elf.c:274 > 274 loc = strstr(sym->name, suffix); > (gdb) bt > #0 find_unsuffixed_func (elf=elf@entry=0x7ffff55a5010, sym=0x0, > suffix=0x416cbf ".cfi_jt", func=func@entry=0x7fffffffd5f0) at > elf.c:274 > #1 0x000000000040d8f8 in read_relocs (elf=0x7ffff55a5010) at elf.c:637 > ... > > In this specific case, find_func_by_offset returns NULL for > .text..L.cfi.jumptable.43 at addend 0x8, because Clang doesn't emit > jump table symbols for static functions: > > 0000000000000000 <__typeid__ZTSFjmiE_global_addr>: > 0: e9 00 00 00 00 jmpq 5 <__typeid__ZTSFjmiE_global_addr+0x5> > 1: R_X86_64_PLT32 io_serial_in-0x4 > 5: cc int3 > 6: cc int3 > 7: cc int3 > 8: e9 00 00 00 00 jmpq d <__typeid__ZTSFjmiE_global_addr+0xd> > 9: R_X86_64_PLT32 mem32_serial_in-0x4 > d: cc int3 > e: cc int3 > f: cc int3 > > Nick, do you remember if there were plans to change this?
Do you have a link to any previous discussion to help jog my mind; I don't really remember this one. Is it that `__typeid__ZTSFjmiE_global_addr` is the synthesized jump table, and yet there is no `__typeid__ZTSFjmiE_global_addr` entry in the symbol table? -- Thanks, ~Nick Desaulniers