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: <CAKv+Gu_J_DxAferEYG7r+OQVSymdWmfxOA-NHBP9JU8AKFeouw@mail.gmail.com>
Date:   Wed, 21 Feb 2018 13:43:34 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Mark Brown <broonie@...aro.org>
Cc:     Will Deacon <will.deacon@....com>, stable@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] arm64 spectre and meltdown mitigations for -stable

On 21 February 2018 at 12:53, Greg KH <gregkh@...uxfoundation.org> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ