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

[Greg KH]

On Wed, Feb 21, 2018 at 01:43:34PM +0000, Ard Biesheuvel wrote:
> 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.

Ugh, I was worried about PAN stuff :(

I'm guessing that the android-common trees might have an easier time of
this, I'll go ask the Google developers what they are considering for
these trees.

> 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).

But we have x86 already working for 4.9.y :)

> 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.

Fair enough, it makes sense not to drag this back to older kernels
unless someone really cares about it.  Thanks for the quick response,
I'll push back on the people asking about it to see if they even can
detect the issue on their devices...

thanks,

greg k-h