linux-kernel - Re: [PATCH] x86/unwind/orc: add ELF section with ORC version number

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230609224803.275vqw345utsusah@treble>
Date:   Fri, 9 Jun 2023 15:48:03 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Omar Sandoval <osandov@...ndov.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, linux-debuggers@...r.kernel.org,
        kernel-team@...com
Subject: Re: [PATCH] x86/unwind/orc: add ELF section with ORC version number

On Fri, Jun 09, 2023 at 03:24:38PM -0700, Omar Sandoval wrote:
> > Though, instead of
> > using an incrementing version, Peter had the idea to hash the struct,
> > like:
> > 
> >   awk '/^struct orc_entry {$/ { p=1 } p { print } /^}/ { p=0 }' arch/x86/include/asm/orc_types.h | sha1sum
> > 
> > That way we don't have to remember to bump the version number, and it
> > would be more resilient to partial backports in distros.
> > 
> > Would something like that work for you?
> 
> Any sort of unique identifier works for me. One thing that the proposed
> hash wouldn't catch is if ORC_REG_* or ORC_TYPE_* are ever renumbered
> (i.e., the meanings of existing values change). It also wouldn't catch
> if something about the .orc_unwind_ip section changed. But assuming
> changes like that would be much rarer, it could be handled manually by
> bumping a "salt" for the hash. E.g., by adding 'BEGIN { print <SALT> }'
> to the awk script:
> 
> awk 'BEGIN { print 1 } /^struct orc_entry {$/ { p=1 } p { print } /^}/ { p=0 }' arch/x86/include/asm/orc_types.h | sha1sum
> 
> I'll defer to you guys whether it's easier to remember to bump a version
> everytime or only in those rare cases.

I think I'd prefer only bumping it in the rare cases, because we're
going to end up forgetting either way ;-)

To catch REG/TYPE changes, we could forego awk and just hash the whole
file, the only downside being that it might introduce unnecessary
changes if we change a comment or something.  But the file changes
rarely enough.

Or we could tweak the awk to also print ORC_{REG,TYPE}_* pretty easily.

-- 
Josh