linux-kernel - Re: [RFC PATCH v4 22/37] arm64: kernel: Skip validation of kuser32.o

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 5 May 2022 11:24:48 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Chen Zhongjin <chenzhongjin@...wei.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-arch@...r.kernel.org, jthierry@...hat.com,
        catalin.marinas@....com, will@...nel.org, masahiroy@...nel.org,
        jpoimboe@...hat.com, ycote@...hat.com, herbert@...dor.apana.org.au,
        mark.rutland@....com, davem@...emloft.net, ardb@...nel.org,
        maz@...nel.org, tglx@...utronix.de, luc.vanoostenryck@...il.com
Subject: Re: [RFC PATCH v4 22/37] arm64: kernel: Skip validation of kuser32.o

On Thu, May 05, 2022 at 11:36:12AM +0800, Chen Zhongjin wrote:
> Hi Peter,
> 
> IIRC now the blacklist mechanisms all run on check stage, which after
> decoding, but the problem of kuser32.S happens in decoding stage. Other
> than that the assembly symbols in kuser32 is STT_NOTYPE and
> STACK_FRAME_NON_STANDARD will throw an error for this.
> 
> OBJECT_FILES_NON_STANDARD works for the single file but as you said
> after LTO it's invalid. However STACK_FRAME_NON_STANDARD doesn't work
> for kuser32 case at all.
> 
> Now my strategy for undecodable instructions is: show an error message
> and mark insn->ignore = true, but do not stop anything so decoding work
> can going on.
> 
> To totally solve this my idea is that applying blacklist before decode.
> However for this part objtool doesn't have any insn or func info, so we
> should add a new blacklist just for this case...

OK, so Mark explained that this is 32bit userspace (VDSO) code.

And as such there's really no point in running objtool on it. Does all
that live in it's own section? Should it?