On Thu, Dec 12, 2013 at 1:00 AM, Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote:
> On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
> <octavian.purdila@xxxxxxxxx> wrote:
>> On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote:
>>>
>>> Assuming you are talking about a kernel compat layer that translates
>>> the flat_binder_object structs as they pass between 32 bit and 64 bit
>>> processes, that will not always work. The data portion of the message
>>> sometimes contain size values that are invisible to the kernel, but
>>> these values will be wrong if the kernel move data to make room for a
>>> different size flat_binder_object.
>>>
>>
>> Hi Arve,
>>
>> Yes, I was talking about translating flat_binder_objects.
>>
>> I understand the potential issue for the user data payload, however,
>> since most applications will use libbinder, the only problematic case
>> is readIntPtr/writeIntPtr, which we can deprecate and convert
>> applications that use it to readInt64. AFAICS there is only one user
>> in the AOSP for this API (libmedia).
>>
>> If you are referring to data blobs that application parses I don't
>> think there is anything we can do, even at libbinder level.
>>
>> Can you give me an example of the sort of problems you see?
>>
>> Thanks,
>> Tavi
>
> The specific problem I was told about can be found in
> frameworks/base/core/java/android/os/Bundle.java, but there could be
> other. The size of the bundle is stored in the parcel so the end of
> the bundle will be wrong if the bundle contains a flat_binder_object
> that the driver changes the size of. However, since the sending
> process gets the parcel size from libbinder, changing libbinder to
> always use the 64 bit version of flat_binder_object should work with
> this code.
>
AFAICS the bundle size is stored as an int32 so there is no bit width
issues between the sending and receiving process.
When I mentioned that flat_binder_objects will be translated, I meant
the whole transaction will be translated to preserve its user payload
intact. Something like this:
32bit 64bit
+----------------+ +--------------------+
| o o oo o xx| -> | oo oooo oo yyyy|
+----------------+ +--------------------+
where o are binder objects, spaces are user data and x,y are offsets
pointers to binder objects (they are size_t so they need translation
as well).
As long as the application does not use absolute offsets in the
payload and as long as the data types stored in the payload are fixed
bit width across the 32bit/64bit ABI (e.g. int32, int64 instead of
intptr) doing the translation in kernel should be fine. I checked
libbinder and both assumptions seems to be true (except in a few cases
for the later which I already mentioned)
So, what am I missing?
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
