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

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:	Tue, 4 Dec 2012 08:17:56 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Serban Constantinescu <serban.constantinescu@....com>
Cc:	arve@...roid.com, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org, john.stultz@...aro.org,
	ccross@...roid.com, zach.pfeffer@...aro.org, Dave.Butcher@....com
Subject: Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit
 binder calls in a 64bit kernel

On Tue, Dec 04, 2012 at 10:44:13AM +0000, Serban Constantinescu 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.
> 
> 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
> solution.
> 
> The patch has been successfully tested on ARMv8 AEM and Versatile
> Express V2P-CA9.

Has it also been properly tested on a 32bit kernel and userspace to
verify that nothing broke?

I was wondering when someone would notice that this code was not going
to work for this type of system, nice to see that you are working to fix
it up.  But, I'll reask Dan's question here, why not use the compat32
ioctl interface instead?  Shouldn't that be the easier way to do this?

Also, one meta comment, never use the uint32_t types, use the native
kernel types (u32 and the like.)  If you are crossing the user/kernel
boundry, use the other correct types for those data structures (__u32
and the like).  What you did here is mix and match things so much that I
really can't verify that it is all correct.

thanks,

greg k-h
--
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/