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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Apr 2013 15:30:13 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Serban Constantinescu <Serban.Constantinescu@....com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	Dave Butcher <Dave.Butcher@....com>
Subject: Re: [PATCH v2 6/7] staging: android: binder: fix alignment issues

On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
<Serban.Constantinescu@....com> wrote:
> On 10/04/13 00:58, Arve Hjønnevåg wrote:
>>
>> On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
>> <serban.constantinescu@....com> wrote:
>>>
>>> The Android userspace aligns the data written to the binder buffers to
>>> 4bytes. Thus for 32bit platforms or 64bit platforms running an 32bit
>>> Android userspace we can have a buffer looking like this:
>>>
>>> platform    buffer(binder_cmd   pointer)      size
>>> 32/32                 32b         32b          8B
>>> 64/32                 32b         64b          12B
>>> 64/64                 32b         64b          12B
>>>
>>> Thus the kernel needs to check that the buffer size is aligned to 4bytes
>>> not to (void *) that will be 8bytes on 64bit machines.
>>>
>>> The change does not affect existing 32bit ABI.
>>>
>>
>> Do we not want the pointers to be 8 byte aligned on 64bit platforms?
>
>
> No since here we do not align pointers we align binder_buffers and offsets
> in a buffer.
>

Do any 64 bit systems align pointers in a struct to 8 bytes? If so, we
should keep the start address of the struct 8 byte aligned as well.

> Let's assume that from the userspace we receive a sequence of BC_INCREFS and
> BC_FREE_BUFFER. According to their definitions the buffer would look like:
>
> Buffer:
> [addr]          [element]
> 0               BC_INCREFS
> 4               __u32
> 8               BC_FREE_BUFFER
> 12              void *        //(8 bytes for 64bit or 4 bytes for 32bit)
>
> Thus the data_size(sizeof(Buffer)) will be 20 bytes for 64bit systems(4bytes
> aligned). Same explanation for offp where it represents the offset form the
> start of the buffer to a flat_binder_object(for example here the offset to
> void* - 12bytes).
>

Does this work on every 64 bit system?

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ