From: Greg KH <gregkh@linuxfoundation.org>
To: David Long <dave.long@linaro.org>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
stable@vger.kernel.org, Florian Fainelli <f.fainelli@gmail.com>,
Julien Thierry <julien.thierry@arm.com>,
Tony Lindgren <tony@atomide.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 4.14 00/17] V4.14 backport of more 32-bit arm spectre patches
Date: Wed, 16 Jan 2019 20:48:42 +0100 [thread overview]
Message-ID: <20190116194842.GA7536@kroah.com> (raw)
In-Reply-To: <78d9e5e0-45cc-dd22-d34a-4a82980c772a@linaro.org>
On Wed, Jan 16, 2019 at 02:40:10PM -0500, David Long wrote:
> On 1/16/19 2:33 PM, Greg KH wrote:
> > On Wed, Jan 16, 2019 at 02:27:13PM -0500, David Long wrote:
> > > On 1/15/19 12:19 PM, Greg KH wrote:
> > > > On Tue, Jan 15, 2019 at 05:06:59PM +0000, Russell King - ARM Linux admin wrote:
> > > > > On Tue, Jan 15, 2019 at 05:30:51PM +0100, Greg KH wrote:
> > > > > > On Tue, Jan 15, 2019 at 11:07:08AM -0500, David Long wrote:
> > > > > > > On 1/15/19 10:45 AM, Greg KH wrote:
> > > > > > > > On Thu, Jan 10, 2019 at 12:51:33PM -0500, David Long wrote:
> > > > > > > > > From: "David A. Long" <dave.long@linaro.org>
> > > > > > > > >
> > > > > > > > > V4.14 backport of spectre patches from Russell M. King's spectre branch.
> > > > > > > >
> > > > > > > > If I take these, than 4.19 is vulnerable. So someone upgrading from
> > > > > > > > 4.14 to 4.19 will regress :(
> > > > > > > >
> > > > > > > > Can you please send me a 4.19 series so I can apply that before this
> > > > > > > > one?
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > greg k-h
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > OK, didn't think about that being a problem. Working on it. Pretty sure
> > > > > > > there's exactly one patch needed for that.
> > > > > >
> > > > > > one? All of these except one showed up in 4.20 and were not backported
> > > > > > to 4.19 from what I can tell. The last one is in 5.0-rc1 and not even
> > > > > > backported to 4.20 either, which means someone messed up and didn't tag
> > > > > > it properly with a cc: stable patch :(
> > > > >
> > >
> > > My bad, I see now I was looking at v4.20 when I made that comment, not
> > > v4.19.
> > >
> > > > > Or they didn't think it was important enough to warrant backporting.
> > > >
> > > > Fair enough, then I have to ask why it's included in this series at
> > > > all...
> > > >
> > >
> > > I've been backporting all "spectre" branch patches as kept in the linux-arm
> > > repo, with the assumption they're all important. If the last patch is not
> > > deemed worthy of going into stable now would be a good time to declare it so
> > > as I have patch sets for v4.19 and v4.9 stable versions about ready to
> > > publish.
> >
> > Isn't it up to you to determine what is and is not important to get this
> > all working properly? You are testing all of this, right? :)
> >
>
> It is all going through kernelci and a local kvm unit test.
That just tests if you didn't break anything, how are you testing that
you really are mitigating the issue that you think you are fixing? What
spectre-specific tests are you using to validate all of this?
> The last patch in this set exists to fix a (apparently) non-critical
> regression in a security patch preceding it. How worried are we about
> patches to stable introducing regressions? My assumption was that this is a
> bad enough thing to be fixed, but maybe not.
You tell me, what is the result if that patch is not applied? Is it a
bug? Performance issue? Documentation issue? Something else?
I understand why it was fixed (cleanups are good to do), but you need to
determine if what the cleanup is doing is actually something that
matters.
thanks,
greg k-h
next prev parent reply other threads:[~2019-01-16 19:48 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 17:51 [PATCH 4.14 00/17] V4.14 backport of more 32-bit arm spectre patches David Long
2019-01-10 17:51 ` [PATCH 4.14 01/17] ARM: 8789/1: signal: copy registers using __copy_to_user() David Long
2019-01-10 17:51 ` [PATCH 4.14 02/17] ARM: 8790/1: signal: always use __copy_to_user to save iwmmxt context David Long
2019-01-10 17:51 ` [PATCH 4.14 03/17] ARM: 8791/1: vfp: use __copy_to_user() when saving VFP state David Long
2019-01-10 17:51 ` [PATCH 4.14 04/17] ARM: 8792/1: oabi-compat: copy oabi events using __copy_to_user() David Long
2019-01-10 17:51 ` [PATCH 4.14 05/17] ARM: 8793/1: signal: replace __put_user_error with __put_user David Long
2019-01-10 17:51 ` [PATCH 4.14 06/17] ARM: 8794/1: uaccess: Prevent speculative use of the current addr_limit David Long
2019-01-10 17:51 ` [PATCH 4.14 07/17] ARM: 8795/1: spectre-v1.1: use put_user() for __put_user() David Long
2019-01-10 17:51 ` [PATCH 4.14 08/17] ARM: 8796/1: spectre-v1,v1.1: provide helpers for address sanitization David Long
2019-01-10 17:51 ` [PATCH 4.14 09/17] ARM: 8797/1: spectre-v1.1: harden __copy_to_user David Long
2019-01-10 17:51 ` [PATCH 4.14 10/17] ARM: 8810/1: vfp: Fix wrong assignement to ufp_exc David Long
2019-01-10 17:51 ` [PATCH 4.14 11/17] ARM: make lookup_processor_type() non-__init David Long
2019-01-10 17:51 ` [PATCH 4.14 12/17] ARM: split out processor lookup David Long
2019-01-10 17:51 ` [PATCH 4.14 13/17] ARM: clean up per-processor check_bugs method call David Long
2019-01-10 17:51 ` [PATCH 4.14 14/17] ARM: add PROC_VTABLE and PROC_TABLE macros David Long
2019-01-10 17:51 ` [PATCH 4.14 15/17] ARM: spectre-v2: per-CPU vtables to work around big.Little systems David Long
2019-01-10 17:51 ` [PATCH 4.14 16/17] ARM: ensure that processor vtables is not lost after boot David Long
2019-01-10 17:51 ` [PATCH 4.14 17/17] ARM: fix the cockup in the previous patch David Long
2019-01-15 15:45 ` [PATCH 4.14 00/17] V4.14 backport of more 32-bit arm spectre patches Greg KH
2019-01-15 16:07 ` David Long
2019-01-15 16:30 ` Greg KH
2019-01-15 16:39 ` David Long
2019-01-15 17:06 ` Russell King - ARM Linux admin
2019-01-15 17:19 ` Greg KH
2019-01-16 19:27 ` David Long
2019-01-16 19:33 ` Greg KH
2019-01-16 19:40 ` David Long
2019-01-16 19:48 ` Greg KH [this message]
2019-01-16 19:49 ` Russell King - ARM Linux admin
2019-01-18 16:07 ` Greg KH
2019-01-18 20:24 ` David Long
2019-01-19 8:08 ` Greg KH
2019-01-19 9:56 ` Russell King - ARM Linux admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190116194842.GA7536@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=broonie@kernel.org \
--cc=dave.long@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=julien.thierry@arm.com \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=stable@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).