Date:   Thu, 22 Oct 2020 19:47:57 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
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, 22 Oct 2020 at 19:38, Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Thu, Oct 22, 2020 at 07:34:38PM +0300, Dmitry Osipenko wrote:
> > 22.10.2020 19:23, Russell King - ARM Linux admin пишет:
> > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > >> On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > >> <linux@...linux.org.uk> wrote:
> > >>>
> > >>> 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.
> > >>
> > >> Why is that better? I provided a minimal fix which has zero impact on
> > >> ARM builds, and minimal impact on Thumb2 builds, given that it retains
> > >> the exact same semantics as before, but using a different opcode.
> > >
> > > I think you just described the reason there. Why should we force
> > > everything to use a different opcode when a short jump _should_
> > > suffice?
> > >
> > > Your patch may be a single line, but it has a slightly greater
> > > impact than the alternative two line solution.
> > >
> >
> > But the two line change isn't portable to stable kernels as-is, isn't it?
>
> Why not?
>

In any case, I'd prefer not to dump VFP exception handling code into
the .vfp11_veneer section, which is documented as below, and typically
empty in our case, given that the only FP code we have in the kernel
is NEON code.



"""
   The '--vfp11-denorm-fix' switch enables a link-time workaround for a
bug in certain VFP11 coprocessor hardware, which sometimes allows
instructions with denorm operands (which must be handled by support
code) to have those operands overwritten by subsequent instructions
before the support code can read the intended values.

   The bug may be avoided in scalar mode if you allow at least one
intervening instruction between a VFP11 instruction which uses a
register and another instruction which writes to the same register, or
at least two intervening instructions if vector mode is in use.  The bug
only affects full-compliance floating-point mode: you do not need this
workaround if you are using "runfast" mode.  Please contact ARM for
further details.

   If you know you are using buggy VFP11 hardware, you can enable this
workaround by specifying the linker option '--vfp-denorm-fix=scalar' if
you are using the VFP11 scalar mode only, or '--vfp-denorm-fix=vector'
if you are using vector mode (the latter also works for scalar code).
The default is '--vfp-denorm-fix=none'.

   If the workaround is enabled, instructions are scanned for
potentially-troublesome sequences, and a veneer is created for each such
sequence which may trigger the erratum.  The veneer consists of the
first instruction of the sequence and a branch back to the subsequent
instruction.  The original instruction is then replaced with a branch to
the veneer.  The extra cycles required to call and return from the
veneer are sufficient to avoid the erratum in both the scalar and vector
cases.
"""

Powered by blists - more mailing lists