linux-kernel - Re: [RFC v5 00/57] objtool: Add support for arm64

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: <20200123143503.GA19649@willie-the-truck>
Date:   Thu, 23 Jan 2020 14:35:03 +0000
From:   Will Deacon <will@...nel.org>
To:     Julien Thierry <jthierry@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        jpoimboe@...hat.com, peterz@...radead.org, raphael.gault@....com,
        catalin.marinas@....com
Subject: Re: [RFC v5 00/57] objtool: Add support for arm64

On Thu, Jan 23, 2020 at 01:52:17PM +0000, Julien Thierry wrote:
> 
> 
> On 1/21/20 10:30 AM, Will Deacon wrote:
> > On Thu, Jan 09, 2020 at 04:02:03PM +0000, Julien Thierry wrote:
> > > This patch series is the continuation of Raphael's work [1]. All the
> > > patches can be retrieved from:
> > > git clone -b arm64-objtool-v5 https://github.com/julien-thierry/linux.git
> > 
> > [...]
> > 
> > >    objtool: arm64: Decode unknown instructions
> > >    objtool: arm64: Decode simple data processing instructions
> > >    objtool: arm64: Decode add/sub immediate instructions
> > >    objtool: arm64: Decode logical data processing instructions
> > >    objtool: arm64: Decode system instructions not affecting the flow
> > >    objtool: arm64: Decode calls to higher EL
> > >    objtool: arm64: Decode brk instruction
> > >    objtool: arm64: Decode instruction triggering context switch
> > >    objtool: arm64: Decode branch instructions with PC relative immediates
> > >    objtool: arm64: Decode branch to register instruction
> > >    objtool: arm64: Decode basic load/stores
> > >    objtool: arm64: Decode load/store with register offset
> > >    objtool: arm64: Decode load/store register pair instructions
> > >    objtool: arm64: Decode FP/SIMD load/store instructions
> > >    objtool: arm64: Decode load/store exclusive
> > >    objtool: arm64: Decode atomic load/store
> > >    objtool: arm64: Decode pointer auth load instructions
> > >    objtool: arm64: Decode load acquire/store release
> > >    objtool: arm64: Decode load/store with memory tag
> > >    objtool: arm64: Decode load literal
> > >    objtool: arm64: Decode register data processing instructions
> > >    objtool: arm64: Decode FP/SIMD data processing instructions
> > >    objtool: arm64: Decode SVE instructions
> > 
> > That's a lot of decoding logic which we already have in
> > arch/arm64/{kernel/insn.c,include/asm/insn.h}. I'd prefer to see this stuff
> > reused or generated from a single source, since it's really easy to get it
> > wrong, has a tendency to bitrot and is nasty to debug.
> > 
> 
> The thing is that the code in those files is mostly encoding logic
> (motivated by BPF) rather than decoding (except for the instruction that
> might be trapped, but these rarely overlap with instructions that objtools
> cares about). I agree that ideally the decoding/encoding should be under
> arch/arm64/lib, I was just a bit weary introducing a lot of decoding code
> under arch/arm64 that wouldn't even be used in kernel code.

Hmm, but kprobes decodes instructions somehow :p

Not saying you have to refactor everything, but I'd hope you could reuse
some of the aarch64_insn_is* and aarch64_insn_extract* functions at least.

Will