This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/18726] Futexes are broken on MIPS/n32
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 27 Jul 2015 17:24:38 +0000
- Subject: [Bug nptl/18726] Futexes are broken on MIPS/n32
- Auto-submitted: auto-generated
- References: <bug-18726-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18726
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 27 Jul 2015, oss at malat dot biz wrote:
> > So why isn't the kernel ensuring that the "int" value conforms to the ABI
> > for int values (by sign-extending) before it gets to a C function in the
> > kernel with an int argument?
> In this case it can't cause any security issues as the value is used only to
The MIPS architecture specification says there is UNPREDICTABLE behavior
if a non-sign-extended value is used with a 32-bit instruction. The
compiler may generate such instructions to work with the int value.
While such architecturally UNPREDICTABLE behavior can't itself cross
privilege boundaries, that only means it doesn't cause a security issue if
such an instruction is executed in userspace - and the problem code is
executing in the kernel. So you're relying on particular combinations of
(compiler code generation, behavior of particular processors on such
inputs) to avoid security issues, which does not seem a good idea.
> After checking implementation of these new syscalls, which were not present
> in my old version, I think the proper fix would be to change futex value to
> signed int type.
Are you saying that in fact the bug was fixed in the kernel, but later
than 2.6.32? Because the conclusion in the kernel community was that the
kernel was the right place to fix this (by always sign-extending affected
syscall arguments on kernel entry). And I think the conclusion from more
recent discussions in the glibc context of a generic API for internal
futex uses in glibc is that unsigned int is the preferred type for futexes
within glibc.
--
You are receiving this mail because:
You are on the CC list for the bug.