[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMP5Xgf=R_VuP=EvMFVuwx=XtTNwQ0Gx-+Fa63DoLH_073WiAQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 15:00:09 -0800
From: Arve Hjønnevåg <arve@...roid.com>
To: Octavian Purdila <octavian.purdila@...el.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Colin Cross <ccross@...roid.com>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
Ian Rogers <irogers@...gle.com>,
Serban Constantinescu <serban.constantinescu@....com>,
lkml <linux-kernel@...r.kernel.org>,
John Stultz <john.stultz@...aro.org>,
David Butcher <Dave.Butcher@....com>,
Rom Lemarchand <romlem@...roid.com>,
Dianne Hackborn <hackbod@...roid.com>
Subject: Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer
On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
<octavian.purdila@...el.com> wrote:
> On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg <arve@...roid.com> 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.
--
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