Re: [GIT PULL] arm64 spectre and meltdown mitigations for -stable

[Ard Biesheuvel]

On 21 February 2018 at 12:53, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
>> Hi Greg,
>>
>> I've put together a tag which includes all of the upstream arm64 spectre and
>> meltdown mitigations based on v4.15. Please could you consider taking this
>> into the 4.15 stable tree?
>>
>> I understand that Ard (cc'd) is using this stack to create a version for 4.14
>> too.
>
> Do you know of anyone working on backporting this patch series to older
> stable trees (i.e. 4.9.y and 4.4.y and possibly 3.18.y?)
>
>
> I had some requests by some chip manufacturers who were wondering about
> this, as they seem to be stuck on older kernels (of their own doing, not
> our fault at all...)
>
> If not, no big deal, I'll just tell them they need to do the work
> themselves if they care about those old kernel trees :)
>

I had a stab at applying this series to v4.9 LTS as well as our own
v4.9 LTS based stable tree (which has backports of lots of arch/arm64
features applied on top), but there are just too many conflicts.
Functionally, I don't think there are any real impediments, but the
interaction with things like PAN emulation and the
feature/errata/alternatives framework make backporting rather tedious.
Combined with the fact that the Meltdown threat is rather theoretical
for most things already deployed, I am not convinced that we are
likely to end up with something that is more secure than what we
started with.

In any case, I don't think this series should serve as the basis for a
backport to v4.9 and earlier, and instead, it should probably focus on
Spectre mitigation only (which is less intrusive AFAICT). We have
someone in Linaro who is in charge of our stable kernel trees, but he
will need help from someone who intimately understands the code. My
focus was v4.14 primarily because of the significance to my team (the
enterprise group in Linaro), and I cannot justify spending a
disproportionate amount of time on kernel versions our members don't
care about.