[GIT PULL] objtool/urgent for v6.4

[GIT PULL] objtool/urgent for v6.4

[Borislav Petkov]

Hi Linus,

please pull one urgent objtool fix for 6.4.

Thx.

---

The following changes since commit 858fd168a95c5b9669aac8db6c14a9aeab446375:

  Linux 6.4-rc6 (2023-06-11 14:35:30 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/objtool_urgent_for_v6.4

for you to fetch changes up to b9f174c811e3ae4ae8959dc57e6adb9990e913f4:

  x86/unwind/orc: Add ELF section with ORC version identifier (2023-06-16 17:17:42 +0200)

----------------------------------------------------------------
- Add a ORC format hash to vmlinux and modules in order for other tools
  which use it, to detect changes to it and adapt accordingly

----------------------------------------------------------------
Omar Sandoval (1):
      x86/unwind/orc: Add ELF section with ORC version identifier

 arch/x86/Makefile                 | 12 ++++++++++++
 arch/x86/include/asm/Kbuild       |  1 +
 arch/x86/include/asm/orc_header.h | 19 +++++++++++++++++++
 arch/x86/kernel/unwind_orc.c      |  3 +++
 include/asm-generic/vmlinux.lds.h |  3 +++
 scripts/mod/modpost.c             |  5 +++++
 scripts/orc_hash.sh               | 16 ++++++++++++++++
 7 files changed, 59 insertions(+)
 create mode 100644 arch/x86/include/asm/orc_header.h
 create mode 100644 scripts/orc_hash.sh

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] objtool/urgent for v6.4

[Linus Torvalds]

On Sun, 25 Jun 2023 at 02:28, Borislav Petkov <bp@alien8.de> wrote:
>
> - Add a ORC format hash to vmlinux and modules in order for other tools
>   which use it, to detect changes to it and adapt accordingly

Hmm. That "hash" is pretty horrendous. If I read that awk script
right, it will change for things like whitespace changes (or comment
changes) as long as they are around those magic #defines or the
'orc_entry' definition.

I've pulled this, but it all seems pretty random and hacky.

              Linus

Re: [GIT PULL] objtool/urgent for v6.4

[pr-tracker-bot]

The pull request you sent on Sun, 25 Jun 2023 11:28:42 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/objtool_urgent_for_v6.4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/300edd751b102715dda0fe44b4bf8442f6ccf9db

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] objtool/urgent for v6.4

[Peter Zijlstra]

On Sun, Jun 25, 2023 at 10:09:25AM -0700, Linus Torvalds wrote:
> On Sun, 25 Jun 2023 at 02:28, Borislav Petkov <bp@alien8.de> wrote:
> >
> > - Add a ORC format hash to vmlinux and modules in order for other tools
> >   which use it, to detect changes to it and adapt accordingly
> 
> Hmm. That "hash" is pretty horrendous. If I read that awk script
> right, it will change for things like whitespace changes (or comment
> changes) as long as they are around those magic #defines or the
> 'orc_entry' definition.

Yes, if those lines get tail comments or someone mucks about with the
whitespace, the hash changes.

The advantage is that if the thing changes we can't forget to increment
a version number -- and this file hasn't had many changes.

The current output looks like:

$ awk '/^#define ORC_(REG|TYPE)_/ { print }/^struct orc_entry {$/ { p=1 }p { print }/^}/ { p=0 }' < arch/x86/include//asm/orc_types.h
#define ORC_REG_UNDEFINED               0
#define ORC_REG_PREV_SP                 1
#define ORC_REG_DX                      2
#define ORC_REG_DI                      3
#define ORC_REG_BP                      4
#define ORC_REG_SP                      5
#define ORC_REG_R10                     6
#define ORC_REG_R13                     7
#define ORC_REG_BP_INDIRECT             8
#define ORC_REG_SP_INDIRECT             9
#define ORC_REG_MAX                     15
#define ORC_TYPE_UNDEFINED              0
#define ORC_TYPE_END_OF_STACK           1
#define ORC_TYPE_CALL                   2
#define ORC_TYPE_REGS                   3
#define ORC_TYPE_REGS_PARTIAL           4
struct orc_entry {
s16             sp_offset;
s16             bp_offset;
#if defined(__LITTLE_ENDIAN_BITFIELD)
unsigned        sp_reg:4;
unsigned        bp_reg:4;
unsigned        type:3;
unsigned        signal:1;
#elif defined(__BIG_ENDIAN_BITFIELD)
unsigned        bp_reg:4;
unsigned        sp_reg:4;
unsigned        unused:4;
unsigned        signal:1;
unsigned        type:3;
#endif
} __packed;
$

I suppose we could add a lint pass to it to clean it up and make it more
consistent, but I don't expect it would buy us much. In fact, then we
have the build depend on the linter being present, which is a fairly big
down-side.

> I've pulled this, but it all seems pretty random and hacky.

Thanks! So our concern was mostly about not being able to accidentally
change things and not notice the change.

If you want we can add an explicit comment to that file to be careful
about things. Omar's purpose is to detect change, the occasional
harmless change is better than not detecting change.