>>> 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,
> right?
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[1]. 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
retesting.
>
> 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
> kernels!
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
> up...
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.
>
> thanks,
>
> greg k-h
>
> [1] 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[2].
>
> [2] 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.
>
