linux-kernel - Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

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]

Message-ID: <0174c738-633e-1fa8-b45f-fdf03b9c2105@gmail.com>
Date:   Thu, 22 Oct 2020 18:56:58 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Kees Cook <keescook@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel
 compilation error

22.10.2020 17:57, Russell King - ARM Linux admin пишет:
> On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
>> The vfp_kmode_exception() function now is unreachable using relative
>> branching in THUMB2 kernel configuration, resulting in a "relocation
>> truncated to fit: R_ARM_THM_JUMP19 against symbol `vfp_kmode_exception'"
>> linker error. Let's use long jump in order to fix the issue.
>>
>> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> 
> I guess the problem is that vfp_support_entry is in .text which tends
> to be at the beginning of the text section, but vfp_kmode_exception
> is in something like .text.vfp_kmode_exception ?

Indeed, vfp_support_entry is at beginning of .text, while
vfp_kmode_exception is near the end.

> Would it be an idea just to change the section name that stuff like
> vfp_support_entry ends up in, rather than making the code less
> efficient?
> 

This works:

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 4fcff9f59947..65f0a2ef3613 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -65,6 +65,7 @@
 #endif
 	.endm

+	.pushsection .vfp11_veneer, "ax"

 @ VFP hardware support entry point.
 @
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 8c9e7f9f0277..30b83b191174 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -642,7 +642,7 @@ static int vfp_starting_cpu(unsigned int unused)
 	return 0;
 }

-void vfp_kmode_exception(void)
+void __section(".vfp11_veneer") vfp_kmode_exception(void)
 {
 	/*
 	 * If we reach this point, a floating point exception has been raised