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  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:	Tue, 18 Feb 2014 16:08:20 -0800
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Serban Constantinescu <serban.constantinescu@....com>,
	Colin Cross <ccross@...roid.com>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH 12/14] staging: binder: Fix ABI for 64bit Android

On Tue, Feb 18, 2014 at 12:32 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Tue, Feb 18, 2014 at 12:02:07PM -0800, John Stultz wrote:
>> On Tue, Feb 18, 2014 at 11:49 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> > On Tue, Feb 18, 2014 at 11:30:26AM -0800, John Stultz wrote:
>> >> On Tue, Feb 18, 2014 at 11:08 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> >> > On Mon, Feb 17, 2014 at 01:58:40PM -0800, John Stultz wrote:
>> >> >> From: Serban Constantinescu <serban.constantinescu@....com>
>> >> >>
>> >> >> This patch fixes the ABI for 64bit Android userspace.
>> >> >> BC_REQUEST_DEATH_NOTIFICATION and BC_CLEAR_DEATH_NOTIFICATION claim
>> >> >> to be using struct binder_ptr_cookie, but they are using a 32bit handle
>> >> >> and a pointer.
>> >> >>
>> >> >> On 32bit systems the payload size is the same as the size of struct
>> >> >> binder_ptr_cookie, however for 64bit systems this will differ. This
>> >> >> patch adds struct binder_handle_cookie that fixes this issue for 64bit
>> >> >> Android.
>> >> >>
>> >> >> Since there are no 64bit users of this interface that we know of this
>> >> >> change should not affect any existing systems.
>> >> >
>> >> > But you are changing the ioctl structures here, what is that going to
>> >> > cause with old programs?
>> >>
>> >> So I'd be glad for Serban or Arve to clarify, but my understanding
>> >> (and as is described in the commit message) is that the assumption is
>> >> there are no 64bit binder users at this point, and the ioctl structure
>> >> changes are made such that existing 32bit applications are unaffected.
>> >
>> > How does changing the structure size, and contents, not affect any
>> > applications or the kernel code?  What am I missing here?
>>
>> On 32bit pointers and ints are the same size? (Years ago I sat through
>> your presentation on this, so I'm worried I'm missing something here
>> :)
>>
>> struct binder_ptr_cookie {
>> void *ptr;
>> void *cookie;
>> };
>>
>> struct binder_handle_cookie {
>> __u32 handle;
>> void *cookie;
>> } __attribute__((packed));
>>
>>
>> On 32bit systems these are the same size.  Now on 64bit systems, this
>> changes things, and would break users, but the assumption here is
>> there are no pre-existing 64bit binder users.
>
> But you added a field to the existing structure, right?  I don't really
> remember the patch, it was a few hundred back in my review of stuff
> today, sorry...
>
> greg k-h

The existing structure is not changed. These two commands were defined
with wrong structure that did not match the code. Since a binder
pointer and handle are the same size on 32 bit systems, this change
does not affect them. On 64 bit systems, the ioctl number does change,
but these systems need the next patch to run 32 bit processes anyway,
so I don't expect anyone to ship a system without this change. The
main purpose of this patch is to add the binder_handle_cookie struct
so the service manager does not have to define its own version
(libbinder writes one field at a time so it does not use the struct).

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists