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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 18 Sep 2017 21:49:05 +0200
From:   Arnd Bergmann <>
To:     Christoph Hellwig <>
Cc:     Greg Kroah-Hartman <>,
        Arve Hjønnevåg <>,
        Riley Andrews <>,, Todd Kjos <>,
        Linux Kernel Mailing List <>,
        John Stultz <>,
        Martijn Coenen <>
Subject: Re: [PATCH] android: binder: fix type mismatch warning

On Mon, Sep 18, 2017 at 6:23 PM, Christoph Hellwig <> wrote:
> On Mon, Sep 18, 2017 at 05:53:47PM +0200, Greg Kroah-Hartman wrote:
>> > It seems like a legitimate use case of the binder modules, but
>> > now there is a kernel Kconfig option that has to match a user
>> > space binary.
>> So, should we revert that?
>> I don't really know what to suggest here, sorry...
> Keep it as is for now, and encourage people to fix it.  But we should
> reject any new patch that makes this worse or adds additional ioctls
> that don't follow our normal model.

I would argue we should leave it as non-configurable, but make
a conscious decision which ABI to use for 4.14, as that is going
to be in a the next generation of Android devices:

interface supported in all 32-bit builds forever, remaining compatible
the ABI that was supported in mainline Linux in all versions until v4.13.
The version 7 interface is incompatible between 32-bit and 64-bit user
space, and there is no compat_ioctl implementation for it, so someone
should fix it by implementing a proper compat_ioctl function.

The current Kconfig comment says that v7 of the ABI is also
incompatible with Android 4.5 and later user space. Can someone
confirm that? The code looks like it's written under the assumption
that user space would dynamically pick between v7 and v8 based
on the return value of ioctl(..., BINDER_VERSION).

We could also add support for switching the ABI dynamically in the
kernel module based on either a module parameter or an ioctl
that a future version of the binder user space can call, to add optional
support for the v8 ABI on 64-bit.

b) Treat the fact that we implemented the v7 binder ABI as a bug,
since real Android uses v8, removing all traces of the v7 code from
the kernel, and requiring users of Android 4.4 and earlier to upgrade
their binder to a version that runs on modern kernels. We can
probably get away with that because
 - Neither arm64 nor x86_64 are affected by this change.
 - "anbox" would normally only be used on x86_64, but not i386
   or arm32
 - we probably already lost support for Android 4.4 and earlier due
   to other kernel changes
 - any arm32 user space that people actually try to run with a
   mainline kernel should already support the v8 ABI, and might not
   support the v7 ABI at all.
 - we don't support v1 through v6 of the interface either.


Powered by blists - more mailing lists