Message-ID: <f47841b0-bbbf-f03a-dfd1-88e92f4db7c6@gmail.com>
Date:   Mon, 24 Aug 2020 09:42:53 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Will Deacon <will@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Marc Zyngier <maz@...nel.org>,
        James Morse <james.morse@....com>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Mark Rutland <mark.rutland@....com>,
        Mark Brown <broonie@...nel.org>,
        Kristina Martsenko <kristina.martsenko@....com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Andrew Jones <drjones@...hat.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Fangrui Song <maskray@...gle.com>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" 
        <kvmarm@...ts.cs.columbia.edu>
Subject: Re: [PATCH stable v4.9 v2] arm64: entry: Place an SB sequence
 following an ERET instruction



On 8/24/2020 9:32 AM, Will Deacon wrote:
> Hi Florian,
> 
> On Fri, Aug 21, 2020 at 10:16:23AM -0700, Florian Fainelli wrote:
>> On 8/21/20 9:03 AM, Will Deacon wrote:
>>> On Fri, Aug 07, 2020 at 03:14:29PM +0200, Greg KH wrote:
>>>> On Thu, Aug 06, 2020 at 01:00:54PM -0700, Florian Fainelli wrote:
>>>>> Greg, did you have a chance to queue those changes for 4.9, 4.14 and 4.19?
>>>>>
>>>>> https://lore.kernel.org/linux-arm-kernel/20200720182538.13304-1-f.fainelli@gmail.com/
>>>>> https://lore.kernel.org/linux-arm-kernel/20200720182937.14099-1-f.fainelli@gmail.com/
>>>>> https://lore.kernel.org/linux-arm-kernel/20200709195034.15185-1-f.fainelli@gmail.com/
>>>>
>>>> Nope, I was waiting for Will's "ack" for these.
>>>
>>> This patch doesn't even build for me (the 'sb' macro is not defined in 4.9),
>>> and I really wonder why we bother backporting it at all. Nobody's ever shown
>>> it to be a problem in practice, and it's clear that this is just being
>>> submitted to tick a box rather than anything else (otherwise it would build,
>>> right?).
>>
>> Doh, I completely missed submitting the patch this depended on that's
>> why I did not notice the build failure locally, sorry about that, what a
>> shame.
>>
>> Would not be the same "tick a box" argument be used against your
>> original submission then? Sure, I have not been able to demonstrate in
>> real life this was a problem, however the same can be said about a lot
>> security related fixes.
> 
> Sort of, although I wrote the original patch because it was dead easy to do
> and saved having to think too much about the problem, whereas the complexity
> of backporting largerly diminishes that imo.
> 
>> What if it becomes exploitable in the future, would not it be nice to
>> have it in a 6 year LTS kernel?
> 
> Even if people are stuck on an old LTS, they should still be taking the
> regular updates for it, and we would obviously need to backport the fix if
> it turned out to be exploitable (and hey, we could even test it then!).
> 
>>> So I'm not going to Ack any of them. As with a lot of this side-channel
>>> stuff the cure is far worse than the disease.
>> Assuming that my v3 does build correctly, which it will, would you be
>> keen on changing your position?
> 
> Note that I'm not trying to block this patch from going in, I'm just saying
> that I'm not supportive of it. Perhaps somebody from Arm can review it if
> they think it's worth the effort.

How about I submit the actual full series (two patches) and we take the 
discussion from there?

Thanks for responding!
-- 
Florian

Powered by blists - more mailing lists