linux-kernel - Re: [PATCH 1/3] arm64: clean up trampoline vector loads

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] [day] [month] [year] [list]

Message-ID: <fb0e19c2c231a5f256303253b92e64f3@remlab.net>
Date:   Wed, 18 Mar 2020 21:48:50 +0200
From:   Remi Denis-Courmont <remi@...lab.net>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     mark.rutland@....com, will@...nel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] arm64: clean up trampoline vector loads

Le 2020-03-18 20:29, Rémi Denis-Courmont a écrit :
> Le keskiviikkona 18. maaliskuuta 2020, 20.06.30 EET Catalin Marinas a 
> écrit :
>> On Wed, Mar 18, 2020 at 05:57:09PM +0000, Catalin Marinas wrote:
>> > On Mon, Mar 16, 2020 at 02:40:44PM +0200, Rémi Denis-Courmont wrote:
>> > > From: Rémi Denis-Courmont <remi.denis.courmont@...wei.com>
>> > >
>> > > This switches from custom instruction patterns to the regular large
>> > > memory model sequence with ADRP and LDR. In doing so, the ADD
>> > > instruction can be eliminated in the SDEI handler, and the code no
>> > > longer assumes that the trampoline vectors and the vectors address both
>> > > start on a page boundary.
>> > >
>> > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@...wei.com>
>> >
>> > I queued the 3 trampoline patches for 5.7. Thanks.
>> 
>> ... and removed. I applied them on top of arm64 
>> for-next/asm-annotations
>> and with defconfig I get:
>> 
>>   LD      .tmp_vmlinux1
>> arch/arm64/kernel/entry.o: in function `tramp_vectors':
>> arch/arm64/kernel/entry.S:838:(.entry.tramp.text+0x43c): relocation
>> truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol
>> `__entry_tramp_data_start' defined in .rodata section in
>> 
>> I haven't bisected to see which patch caused this issue.

It's the third patch.

> Uho, right :-( It only builds with SDEI enabled :-$
> 
> I'll check further.

It seems that the SYM_DATA_START macro does not align the data on its 
natural boundary. I guess that is all fine on x86 where data needs not 
be aligned, but it leads to this kind of mischief on arm64. Though even 
then, the address is of course actually aligned correctly on an 8-bytes 
boundary, so I suppose binutils is just being pointlessly pedantic here?

-- 
Rémi Denis-Courmont