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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230626081759.GU83892@hirez.programming.kicks-ass.net>
Date:   Mon, 26 Jun 2023 10:17:59 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Borislav Petkov <bp@...en8.de>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>, osandov@...com,
        jpoimboe@...nel.org
Subject: Re: [GIT PULL] objtool/urgent for v6.4

On Sun, Jun 25, 2023 at 10:09:25AM -0700, Linus Torvalds wrote:
> On Sun, 25 Jun 2023 at 02:28, Borislav Petkov <bp@...en8.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.