linux-kernel - Re: [RFC PATCH v2 00/13] objtool: add base 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: <47cb7299-a361-6036-fc6e-860bbcfc2476@redhat.com>
Date:   Tue, 9 Mar 2021 15:27:25 +0100
From:   Julien Thierry <jthierry@...hat.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will@...nel.org>, ycote@...hat.com,
        Fangrui Song <maskray@...gle.com>,
        Bill Wendling <morbo@...gle.com>,
        Pete Swain <swine@...gle.com>,
        Yonghyun Hwang <yonghyun@...gle.com>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [RFC PATCH v2 00/13] objtool: add base support for arm64



On 3/6/21 1:04 AM, Nick Desaulniers wrote:
> On Fri, Mar 5, 2021 at 3:51 PM Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>>
>> (in response to
>> https://lore.kernel.org/linux-arm-kernel/20210303170932.1838634-1-jthierry@redhat.com/
>> from the command line)
>>
>>> Changes since v1[2]:
>>> - Drop gcc plugin in favor of -fno-jump-tables
>>
>> Thank you for this!  I built+booted(under emulation) arm64 defconfig and built
>> arm64 allmodconfig with LLVM=1 with this series applied.
>>
>> Tested-by: Nick Desaulniers <ndesaulniers@...gle.com>
>>
>> One thing I noticed was a spew of warnings for allmodconfig, like:
>> init/main.o: warning: objtool: asan.module_ctor()+0xc: call without frame pointer save/setup
>> init/main.o: warning: objtool: asan.module_dtor()+0xc: call without frame pointer save/setup
>>
>> I assume those are from the KASAN constructors. See also:
>> https://github.com/ClangBuiltLinux/linux/issues/1238
>>
>> Can we disable HAVE_STACK_PROTECTOR if CC_IS_CLANG and CONFIG_KASAN is set,
>> until we can resolve the above issue?

So that concerns objtool for all arches, right?

> 
> Ah, filtering the logs more, it looks like GCOV is has the same issue
> KASAN does (known issue).  Here's a filtered log:
> https://gist.github.com/nickdesaulniers/01358015b33bd16ccd7d951c4a8c44e7
> 
> I'm curious about the failure to decode certain instructions?
> 

This is probably related to data constants present in code sections. To 
fix this, objtool needs to handle SYM_DATA_* annotations [1] and then 
the relevant bytes need to be annotated in the kernel sources (e.g. [2], 
but there are multiple parts in arm64 assembler needing this). I have 
not submitted those yet because I didn't want the amount of patches to 
become overwhelming and mixing objtool + kernel sources.

[1] 
https://github.com/julien-thierry/linux/commit/9005e9f3bb10aac663c42bb87d337b7a1aae5a67

[2] 
https://github.com/julien-thierry/linux/commit/ad132b032b4141c7ffce95d784b5254120e5bf65

> The stack state mismatches are what are valuable to me; we'll need
> some help digging into those at some point.  The logs from defconfig
> are clean.
> 

I think at the moment this is mostly a limitation of objtool to track 
code flow. aarch64 code tends to do a lot more register load/store 
inside a function than x86, and objtool doesn't track multiple register 
states (e.g. a registered stored at some offset on the stack at the 
beginning of the function, and later at some other stack offset). 
Although, when looking at the disassembled code, I'm not 100% I 
understand why there are so many intermediary store/load for these 
registers since it doesn't look like those values are actually used (I 
don't know whether this is caused by kasan/probes instrumentation).

But I'd need to investigate a bit more.

-- 
Julien Thierry