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?
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.
On Thu, May 05, 2022 at 11:56:45AM +0100, Mark Rutland wrote:
> 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?
On x86, we just use OBJECT_FILES_NON_STANDARD (like the up-thread patch)
to tell objtool to ignore all the vdso objects.
That should be fine for vdso, since it doesn't actually end up as text
in vmlinux.
--
Josh