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: <ad6f3a12-60b9-f2d8-b0c9-0de59c0e0c2c@redhat.com>
Date:   Thu, 23 Jan 2020 15:11:20 +0000
From:   Julien Thierry <jthierry@...hat.com>
To:     Will Deacon <will@...nel.org>
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 1/23/20 2:35 PM, Will Deacon wrote:
> 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.
> 

Oh, you're right, there seem to be more than what I remembered. There is 
probably a bunch of things I can reuse (and I'll feel more at ease with 
that rather than introducing a whole bunch of new code :D ).

Thanks,

-- 
Julien Thierry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ