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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 6 May 2022 10:18:10 +0800
From:   Chen Zhongjin <chenzhongjin@...wei.com>
To:     Mark Rutland <mark.rutland@....com>,
        Peter Zijlstra <peterz@...radead.org>
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>, <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 2022/5/5 18:56, Mark Rutland wrote:
> On Thu, May 05, 2022 at 11:24:48AM +0200, Peter Zijlstra wrote:
>> 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?
> 
> It's placed in .rodata by a linker script:
> 
> * The 32-bit vdso + kuser code is placed in .rodata, between the `vdso32_start`
>   and `vdso32_end` symbols, as raw bytes (via .incbin).
>   See arch/arm64/kernel/vdso32-wrap.S.
> 
> * The 64-bit vdso code is placed in .rodata, between the `vdso_start`
>   and `vdso32` symbols, as raw bytes (via .incbin).
>   See arch/arm64/kernel/vdso-wrap.S.
> 
> The objects under arch/arm64/kernel/{vdso,vdso32}/ are all userspace objects,
> and from userspace's PoV the existing secrtions within those objects are
> correct, so I don't think those should change.
> 
> How does x86 deal with its vdso objects?
> 
> Thanks,
> Mark.
> .

However for my build kuser32.o content is in .text and there is only
`vdso` symbol in .rodata without `vdso32`. And for defconfig the
CONFIG_KUSER_HELPERS=y is on.

According to your description, it seems something wrong here?

If all 32-bit asm is placed in .rodata it won't cause problem for
objtool check.

Thanks!