Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit bindercalls in a 64bit kernel

From: Serban Constantinescu
Date: Wed Dec 05 2012 - 09:53:40 EST

On 05/12/12 00:26, Arve Hjønnevåg wrote:
On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu
<serban.constantinescu@xxxxxxx> wrote:
Android's IPC, Binder, does not support calls from a 32-bit userspace
in a 64 bit kernel. This patch adds support for syscalls coming from a
32-bit userspace in a 64-bit kernel.

It also seems to remove support for 64-bit user-space in a 64 bit
kernel at the same time. While we have not started fixing this problem
yet, it is not clear that we want to go in this direction. If we want
to have any 64 bit user-space processes, the 32-bit processes need to
use 64 bit pointers when talking to other processes. It may make more
sense to change the user-space binder library to probe for needed
pointer size (either by adding an ioctl to the driver to return the
pointer size in an ioctl with a fixed size pointer or by calling
BINDER_VERSION with the two pointer sizes you support (assuming long
and void * are the same size)).

Thanks for the feedback! As described in my previous e-mail, since the
binder uses 2 layer ioctl we can't know from the top of the ioctl
handler what is the size of the incoming package. Therefore we can't
have the same ioctl call servicing both 32bit requests and 64bit
requests in a 64bit kernel. I consider that the way forward would be to
support the existing 32bit user space in a 64bit kernel (allowing
backwards compatibility and what this patch implements) and to extend
the ioctl space with the needed functionality when and if we will get to
64bit Android. Please correct me if I am wrong.

Most of the changes were applied to types that change sizes between
32 and 64 bit world. This will also fix some of the issues around
checking the size of an incoming transaction package in the ioctl
switch. Since the transaction's ioctl number are generated using
_IOC(dir,type,nr,size), a different userspace size will generate
a different ioctl number, thus switching by _IOC_NR is a better

I don't understand this change. If you use _IOC_NR you lose the
protection that the _IOC macros added. If the size does not match you
still dereference the pointer using the size that the kernel has
(expect where you added a new size check to replace the one you

Take the following snippet as an example:
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)

unsigned int size = _IOC_SIZE(cmd);

switch (cmd) {
struct binder_write_read bwr;
if (size != sizeof(struct binder_write_read)) {
ret = -EINVAL;
goto err;

since BINDER_WRITE_READ is defined as:

#define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)

the size checking done here is not of any use since a different size
would fall in default. Therefore I thought a nicer version would be to
switch by the _IOC_NR() - in this case 1, but with the protection
offered by dir - 'b'. Once again correct me if I am wrong.

Kind regards,
Serban Constantinescu

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at