kpatch-build: account for __pfx_-less NOP padding

[joe-lawrence]

Some kernel configurations generate function NOP padding, but without associated _pfx symbols. For example:

  $ git describe HEAD
  v6.4-rc7-72-gdad9774deaf1

  # Initial default config turns on Indirect Branch Tracking and 16-NOP padding bytes
  $ make defconfig
  $ grep -e CONFIG_X86_KERNEL_IBT -e CONFIG_FUNCTION_PADDING_BYTES .config
  CONFIG_X86_KERNEL_IBT=y
  CONFIG_FUNCTION_PADDING_BYTES=16

  # Test .o build generates 16 bytes of NOPs but no "__pfx_" symbol
  $ make -j$(nproc) fs/proc/cmdline.o
  $ objdump -Dr -j .text fs/proc/cmdline.o  | grep -e '<.*>:' -e 'Disassembly'
  Disassembly of section .text:
  0000000000000000 <cmdline_proc_show-0x10>:
  0000000000000010 <cmdline_proc_show>:

This is because objtool operation on the object code may be delayed under certain configurations. As such, create-diff-object should be prepared to encounter NOP padded functions in object files before any _pfx symbols are created.

Fixes: 3e54c63 ("create-diff-object: support x86 NOP-padded functions")
Closes: #1347 ("x86 NOP padded functions without _pfx symbol")

[joe-lawrence]

Internal testing notes: Ryan reports that this fixes x86-64 integration tests for the v6.3 upstream kernel when CONFIG_X86_KERNEL_IBT=y

[jpoimboe]

Unfortunately I'm not sure this approach is safe (see the discussion in #1320). We may have to add support for running create-diff-object on vmlinux.o.

[joe-lawrence]

Unfortunately I'm not sure this approach is safe (see the discussion in #1320). We may have to add support for running create-diff-object on vmlinux.o.

Ah right thanks for referencing that, I had filed that in my brain as an LTO-specific issue.

I'll close this PR, but should we consider throwing an error on CONFIG_X86_KERNEL_IBT=y until we figure out the eventual game plan?

[jpoimboe]

I'll close this PR, but should we consider throwing an error on CONFIG_X86_KERNEL_IBT=y until we figure out the eventual game plan?

Yeah, that would probably be a good idea.

[github-actions]

This PR has been open for 60 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

[github-actions]

This PR was closed because it was inactive for 7 days after being marked stale.