>>> But really, I don't see this need as all ARM devices that I know of that
>>> are stuck on 4.9.y are already using the android-common tree. Same for
>>> 4.4.y. Do you know of any that are not, and that can not just use
>>> 4.14.y instead?
>> There's way more to ARM than just Android systems, assuming that getting
>> things into the Android kernel is enough is like assuming that x86 is
>> covered since the distros have their own backports - it covers a lot of
>> users but not everyone. Off the top of my head there's things like
>> routers, NASs, cameras, IoT, radio systems, industrial appliances, set
>> top boxes and these days even servers. Most of these segments are just
>> as conservative about taking new kernel versions on shipping product as
>> the phone vendors are, the practices that make people relucant to take
>> bigger updates in production are general engineering practices common
>> across industry.
> I know there is lots more than Android to ARM, but the huge majority by
> quantity is Android.
> What I'm saying here is look at all of the backports that were required
> to get this working in the android tree. It was non-trivial by a long
> shot, and based on that work, this series feels really "small" and I'm
> really worried that it's not really working or solving the problem here.>
> There are major features that were backported to the android trees for
> ARM that the upstream features for Spectre and Meltdown built on top of
> to get their solution. To not backport all of that is a huge risk,
Thanks for response!
Yes, that is problem I concern, current android is far from enough to
protect it self form these two bugs. There are lots of fix missed. like
the main fix patch from upstream isn't included:
arm64: Add skeleton to harden the branch predictor against aliasing attacks
commit 0f15adbb2861 upstream.
BTW, The concept of 2 bugs mitigation is relatively simple, and current
backporting include everything that arm did to mitigate them.
> So that's why I keep pointing people at the android trees. Look at what
> they did there. There's nothing stoping anyone who is really insistant
> on staying on these old kernel versions from pulling from those branches
> to get these bugfixes in a known stable, and tested, implementation.
> That's why I point people there. To do all of the backporting and
> add the new features feels _way_ beyond what I should be taking into the
> stable kernels. We didn't do it for x86, why should we do it for ARM?
Thanks for your effort! That's the reason, LTS need spectre/meltdown fix
on ARM, people like to keep using them system with a simple
kernel/fireware update, instead of whole system update with whole system
> Yes, we did a horrid hack for the x86 backports (with the known issues
> that it has, and people seem to keep ignoring, which is crazy), and I
> would suggest NOT doing that same type of hack for ARM, but go grab a
> tree that we all know to work correctly if you are suck with these old
We know things aren't perfect in urgency fix, that's a reason for x86
story. but for arm side, arm had 3 versions fix, and do update 2 times
on them website, we did 2 times backport too for their fix. Obviously
arm get more time and take more lesson from x86 story for their fix.
> Or just move to 4.14.y. Seriously, that's probably the safest thing in
> the long run for anyone here. And when you realize you can't do that,
> go yell at your SoC for forcing you into the nightmare that they conned
> you into by their 3+ million lines added to their kernel tree. You were
> always living on borowed time, and it looks like that time is finally
yes, that's true. But compare to x86 market, backport to old stable
kernel would save much time for arm vendors and free them to more
new/upstream work instead.
> greg k-h
>  It's also why I keep doing the LTS merges into the android-common
> trees within days of the upstream LTS release (today being an
> exception). That way once you do a pull/merge, you can just keep
> always merging to keep a secure device that is always up to date
> with the latest LTS releases in a simple way. How much easier can I
> make it for the ARM ecosystem here, really?
> Oh, I know, get the SoC vendors to merge from the android-common
> trees into their trees. Look, that's already happening today for at
> least 3 major SoCs! So just go pull the update from your SoC today,
> for your chip, and it automatically has all of these fixes in it
> already! If you know a SoC that is not pulling these updates
> regularly, let me know and I'll work with them to resolve that.
>  I have offered to do that merge myself, from the android-common
> trees into any "internal" tree, so that future merges happen cleanly
> and automatically, for any company that asks for it. So far only
> one company has taken me up on it, and it only took me a week to get
> it all up and working properly. It took a ton of "fun" quilt and
> git work, but in the end, it all worked, and has worked cleanly
> since then, showing it can be done.