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: <20201022161118.GP1551@shell.armlinux.org.uk>
Date:   Thu, 22 Oct 2020 17:11:18 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Dmitry Osipenko <digetx@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Ingo Molnar <mingo@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel
 compilation error

On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko <digetx@...il.com> wrote:
> >
> > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > On Thu, 22 Oct 2020 at 05:30, Kees Cook <keescook@...omium.org> wrote:
> > >>
> > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> > >>> 22.10.2020 02:40, Kees Cook пишет:
> > >>>> 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.
> > >>>>
> > >>>> Eek. Is this with gcc or clang?
> > >>>
> > >>> GCC 9.3.0
> > >>>
> > >>>>> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
> > >>>>
> > >>>> Are you sure it wasn't 512dd2eebe55 ("arm/build: Add missing sections") ?
> > >>>> That commit may have implicitly moved the location of .vfp11_veneer,
> > >>>> though I thought I had chosen the correct position.
> > >>>
> > >>> I re-checked that the fixes tag is correct.
> > >>>
> > >>>>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> > >>>>> ---
> > >>>>>  arch/arm/vfp/vfphw.S | 3 ++-
> > >>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>>>>
> > >>>>> diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
> > >>>>> index 4fcff9f59947..6e2b29f0c48d 100644
> > >>>>> --- a/arch/arm/vfp/vfphw.S
> > >>>>> +++ b/arch/arm/vfp/vfphw.S
> > >>>>> @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > >>>>>    ldr     r3, [sp, #S_PSR]        @ Neither lazy restore nor FP exceptions
> > >>>>>    and     r3, r3, #MODE_MASK      @ are supported in kernel mode
> > >>>>>    teq     r3, #USR_MODE
> > >>>>> -  bne     vfp_kmode_exception     @ Returns through lr
> > >>>>> +  ldr     r1, =vfp_kmode_exception
> > >>>>> +  bxne    r1                      @ Returns through lr
> > >>>>>
> > >>>>>    VFPFMRX r1, FPEXC               @ Is the VFP enabled?
> > >>>>>    DBGSTR1 "fpexc %08x", r1
> > >>>>
> > >>>> This seems like a workaround though? I suspect the vfp11_veneer needs
> > >>>> moving?
> > >>>>
> > >>>
> > >>> I don't know where it needs to be moved. Please feel free to make a
> > >>> patch if you have a better idea, I'll be glad to test it.
> > >>
> > >> I might have just been distracted by the common "vfp" prefix. It's
> > >> possible that the text section shuffling just ended up being very large,
> > >> so probably this patch is right then!
> > >>
> > >
> > > I already sent a fix for this issue:
> > >
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > >
> >
> > The offending commit contains stable tag, so I assume that fixes tag is
> > mandatory. Yours patch misses the fixes tag.
> 
> Russell, mind adding that? Or would you like me to update the patch in
> the patch system?

Rather than adding the IT, I'm suggesting that we solve it a different
way - ensuring that the two bits of code are co-located. There's no
reason for them to be separated, and the assembly code entry point is
already called indirectly.

The problem is the assembly ends up in the .text section which ends up
at the start of the binary, but depending on the compiler, functions
in .c files end up in their own sections. It would be good if, as
Dmitry has shown that it is indeed possible, to have them co-located.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!