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: <CAMj1kXEJL31KOMs7h_XzxFKXgqi2jOXCmLaxfKwW=wgo2so_RA@mail.gmail.com>
Date:   Mon, 9 Nov 2020 08:25:17 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        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 Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko <digetx@...il.com> wrote:
>
> 03.11.2020 10:24, Ard Biesheuvel пишет:
> > Still broken today
> >
> > https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
> >

Still broken today

https://kernelci.org/build/id/5fa898baa00b5f3167db8857/

> > So the options are
> >
> > a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> > b) merge Dmitry's patch that adds an unconditional literal load to all builds
> > c) remove kernel mode handling from vfp_support_entry() [my other patch]
> > d) move sections around so that vfp_kmode_exception is guaranteed to
> > be in range.
> > e) do nothing
> >
> > Given the lack of reports about this issue, it is pretty clear that
> > few people use the Thumb2 build (which I find odd, tbh, since it
> > really is much smaller).
>
> I waited for about a month, hoping that somebody will fix this problem
> before bothering with bisection, which took quite some time and effort
> because intermediate commits were broken, and then with creating and
> sending a patch :)
>
> Thumb2 usually is untested by CI farms and in a case of personal use
> it's easier to wait for a fix. Hence no much reports, I suppose.
>
> > However, that means that a) is a reasonable
> > fix, since nobody will notice the potential performance hit either,
> > and it can easily be backported to wherever the breakage was
> > introduced. (Note that eff8728fe698, which created the problem is
> > marked cc:stable itself).
>
> The performance argument is questionable to me, to be honest. In
> practice the performance difference should be absolutely negligible for
> either of the proposed options, it should stay in a noise even if
> somebody thoroughly counting cycles, IMO.
>
> I'm still thinking that the best option will be to apply a).
>

Can we take that as an acked-by?

> > Going forward, I can refine d) so that we can get rid of the kernel
> > mode path entirely.
>
> And then improve it using d).