lkml.org 
[lkml]   [2018]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9
    From
    Date

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

    \
     
     \ /
      Last update: 2018-03-07 04:28    [W:4.709 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site