linux-kernel - Re: [PATCH] android: binder: fix type mismatch warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAB0TPYFB02ZZmcTpuirmih+B0PTcg_7WybScizoqJtac9=2jNw@mail.gmail.com>
Date:   Fri, 22 Sep 2017 14:46:21 +0200
From:   Martijn Coenen <maco@...roid.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Riley Andrews <riandrews@...roid.com>,
        devel@...verdev.osuosl.org, Todd Kjos <tkjos@...roid.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH] android: binder: fix type mismatch warning

On Fri, Sep 22, 2017 at 11:12 AM, Arnd Bergmann <arnd@...db.de> wrote:
> How would waiting help?

Once P drops support for v7, all P userspaces (including containerized
ones) need to be v8. After a while, the number of non-Android
userspaces < P with v7 would become practically zero. But it's really
hard to draw a line when it is "good enough", so I agree with you it
doesn't really help, it just reduces the chance that somebody will be
affected by it.

> The relevant cases would seem to be:
>
> 1. updating a 32-bit Android Oreo (or earlier) OS from linux-4.9
>     (or earlier) to linux-4.14 (or later) without updating libbinder:
>     This would require keeping around compile-time option
>     at least, for as long new kernels are supported on Oreo.

I think it is unlikely a vendor would upgrade their kernel from
linux-4.9 to linux-4.14 on an already launched Android device - it is
just too much work. Vendors ideally should pick an LTS kernel and
stick with it. But of course we can't rule it out. If it does happen,
I don't think it would be strange to expect vendors to upgrade their
userspace along with it. Many vendors (sadly) have a ton of patches on
top of mainline, that may contain non-ABI-stable interfaces in the
first place, and therefore would require a userspace push anyway.

> 2. updating a 32-bit kernel to a 64-bit kernel on hardware
>     that allows this, without changing anything else:
>     Theoretically fixable, but this would require significant
>     code changes in the kernel module, similar to what I
>     described above.

This is an issue independent of what we do here; if you used the v7
interface in your pre-4.14 32-bit kernel, you have to migrate to v8
simply because the v7 interface can't work with a (pre-4.14) 64-bit
kernel. If you upgrade to a 4.14 kernel from which v7 is removed, you
fall back to the previous case. Such a change would anyway require
building and deploying a new Android userspace, assuming you'd want to
allow running 64-bit userspace applications on such a kernel. I'm not
sure whether there are good reasons to switch to a 64-bit kernel while
maintaining a 32-bit only userspace.

> What assumptions can we make about the two problematic
> cases (1 and 2) here? Is it reasonable to require device
> makes to always update libbinder together with the kernel?

I personally think this is reasonable. Rolling out an update to an
Android device involves a lot of work; if you're going to update the
kernel, you'll often want to use the opportunity to update userspace
as well for things like security fixes. Project Treble has made it
significantly easier to update individual parts of Android.
Unfortunately binder is so pervasive that it touches pretty much
everything - migrating from v7 to v8 will require a full userspace
push. Again, I don't think this is a problem, because:
1) Launched Android devices tend to stick with the kernel version they
launched with (so v7 will stay available to them)
2) If they do want to upgrade, I don't think it's unreasonable to ask
them to do a userspace push along with it
3) New devices launching with 4.14 (and P) will have no choice to use
anything but v8

> Could that run into problems after a botched upgrade that
> reverts back to an older kernel but keeps the new user space
> or vice versa?

Our current A/B partition scheme keeps a complete copy of both the old
kernel and userspace when upgrading; if the upgrade doesn't boot, we
revert both back to the old state.