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

[Chen Zhongjin]

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...

On 2022/4/29 19:05, Peter Zijlstra wrote:
> On Fri, Apr 29, 2022 at 05:43:40PM +0800, Chen Zhongjin wrote:
>> From: Raphael Gault <raphael.gault at arm.com>
>>
>> kuser32 being used for compatibility, it contains a32 instructions
>> which are not recognised by objtool when trying to analyse arm64
>> object files. Thus, we add an exception to skip validation on this
>> particular file.
>>
>> Signed-off-by: Raphael Gault <raphael.gault at arm.com>
>> Signed-off-by: Julien Thierry <jthierry at redhat.com>
>> Signed-off-by: Chen Zhongjin <chenzhongjin at huawei.com>
>> ---
>>  arch/arm64/kernel/Makefile | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 986837d7ec82..c4f01bfe79b4 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -41,6 +41,9 @@ obj-$(CONFIG_COMPAT)			+= sys32.o signal32.o			\
>>  					   sys_compat.o
>>  obj-$(CONFIG_COMPAT)			+= sigreturn32.o
>>  obj-$(CONFIG_KUSER_HELPERS)		+= kuser32.o
>> +
>> +OBJECT_FILES_NON_STANDARD_kuser32.o := y
> 
> File based skipping is depricated in the face of LTO and other link
> target based objtool runs.
> 
> Please use function based blacklisting as per the previous patch.
> 
> .