[SRU][Xenial] Xenial update to 4.4.118 stable release

[Juerg Haefliger]

On 04/04/2018 02:21 PM, Stefan Bader wrote:
> On 04.04.2018 13:40, Juerg Haefliger wrote:
>> On 04/04/2018 12:20 PM, Kleber Souza wrote:
>>> On 04/03/18 14:40, Juerg Haefliger wrote:
>>>> BugLink: http://bugs.launchpad.net/bugs/1756866
>>>>
>>>> This is a pull request for the Xenial stable update from 4.4.117 to
>>>> 4.4.118. The most notable change is the replacement of our spectre v1
>>>> implementation with upstream's version. Specifically, the following
>>>> patches are reverted:
>>>>
>>>> UBUNTU: SAUCE: arm: no osb() implementation yet"
>>>> UBUNTU: SAUCE: arm64: no osb() implementation yet"
>>>> UBUNTU: SAUCE: s390/spinlock: add osb memory barrier"
>>>> UBUNTU: SAUCE: powerpc: add osb barrier"
>>>> UBUNTU: SAUCE: claim mitigation via observable speculation barrier"
>>>> userns: prevent speculative execution"
>>>> udf: prevent speculative execution"
>>>> net: mpls: prevent speculative execution"
>>>> fs: prevent speculative execution"
>>>> ipv6: prevent speculative execution"
>>>> ipv4: prevent speculative execution"
>>>> Thermal/int340x: prevent speculative execution"
>>>> qla2xxx: prevent speculative execution"
>>>> carl9170: prevent speculative execution"
>>>> UBUNTU: SAUCE: FIX: x86, bpf, jit: prevent speculative execution when
>>>> JIT is enabled"
>>>> x86, bpf, jit: prevent speculative execution when JIT is enabled"
>>>> bpf: prevent speculative execution in eBPF interpreter"
>>>> locking/barriers: introduce new observable speculation barrier"
>>>> UBUNTU: SAUCE: reinstate MFENCE_RDTSC feature definition"
>>>> x86/cpu/AMD: Remove now unused definition of MFENCE_RDTSC feature"
>>>>
>>>> And their functionality is (partially?) replaced by upstream's patchset:
>>>>
>>>> x86/kvm: Update spectre-v1 mitigation
>>>> x86/spectre: Report get_user mitigation for spectre_v1
>>>> nl80211: Sanitize array index in parse_txq_params
>>>> vfs, fdtable: Prevent bounds-check bypass via speculative execution
>>>> x86/syscall: Sanitize syscall table de-references under speculation
>>>> x86/get_user: Use pointer masking to limit speculation
>>>> x86: Introduce barrier_nospec
>>>> x86: Implement array_index_mask_nospec
>>>> array_index_nospec: Sanitize speculative array de-references
>>>> Documentation: Document array_index_nospec
>>>>
>>>> Note that v1 of the patchset submitted upstream [1] was more or less
>>>> what we have pulled into Xenial. What's missing from that submittal
>>>> compared to what we have are the bpf/jit patches and some of the osb()
>>>> sprinkling throughout various subsystems and drivers. There was back and
>>>> forth arguing in upstream about whether some of the places that the v1
>>>> patchset modified were even user-space controllable and they eventually
>>>> got dropped form the final v6 version [2]. Plus they added syscall and
>>>> get_user sanitization.
>>>>
>>>> Also, the current upstream implementation is x86 only. PowerPC is in the
>>>> works [3] but no s390x as of yet.
>>>>
>>>> [1] https://lkml.org/lkml/2018/1/5/769
>>>> [2] https://lkml.org/lkml/2018/1/29/960
>>>> [3] https://lkml.org/lkml/2018/3/15/929
>>>>
>>>>
>>>> Let me know if you think we should bring back some or all of the stuff
>>>> that got dropped (powerpc, s390x, bpf).
>>>
>>> Since the spectre v1 changes from upstream hasn't yet been carefully
>>> reviewed and tested by our team, I will not apply this stable update
>>> (and any subsequent ones) until we are more confident about it.
>>
>> We're falling more and more behind. Upstream is at 4.4.126 now. Would it
>> make sense to just skip those patches and continue? Assuming we don't
>> run into issues with future patches because of this.
> 
> It would be good to catch up. But for that we need to rework 4.4.118 to skip
> over the related patches (plus some document which carries what has been skipped
> in total).

I can add the list of skipped patches to the tracking bug. Probably with
a note that we need to revisit this.


> And then continue from there, hoping for no issues.
> That doc I imagine to contain everything skipped (oneline format?) because of
> being spectre related grouped by stable version. Then whomever has to do that
> final review can work with that? What do the others think?
> 
> Just for the current cycle I sadly cannot see us getting more done than up to
> 4.4.117.

I think those are pretty isolated patches so skipping them should be
easy. I can work on a new 4.4.118 today. When's the deadline for this cycle?

...Juerg


> -Stefan
> 
>>
>> ...Juerg