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]
Message-ID: <CAMP5Xgf-HC7Lk=mOE-7prksbOu886q2=YMC8PvS2vFu1L9D1ow@mail.gmail.com>
Date:	Tue, 4 Dec 2012 16:26:11 -0800
From:	Arve Hjønnevåg <arve@...roid.com>
To:	Serban Constantinescu <serban.constantinescu@....com>
Cc:	gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org, john.stultz@...aro.org,
	ccross@...roid.com, zach.pfeffer@...aro.org, Dave.Butcher@....com,
	Dianne Hackborn <hackbod@...roid.com>
Subject: Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit
 binder calls in a 64bit kernel

On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu
<serban.constantinescu@....com> 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)).

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

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
removed).

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