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 16:51:18 +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 #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 27 Jul 2015, oss at malat dot biz wrote:
> In that case the fix is not going to be so simple (I will check the code), but
> I still think ARGIFY is wrong:
> - Assume the futex value is 0x8000 0000.
> - Because it's unsigned, ARGIFY expands to
> ((long long) (unsigned) (0x8000 0000))
> so the content of the register is:
> 0x0000 0000 8000 0000
> - Then the futex syscall is made and the kernel loads the value for
> comparison from the provided memory address into an unsigned variable
> (using load word instruction)
But the code in the kernel that handles syscall arguments should have
sign-extended the register value before it ever reached the C
implementation of futex in the kernel with a 32-bit argument type, so it
shouldn't matter what the high word of the register passed to the kernel
was. If the syscall wrapper code in the kernel doesn't do so, then
hostile userspace code can cause security issues by passing values to the
kernel that result in C code having register values for arguments that
don't conform to the ABI and so undefined behavior in that C code. And
because of the privilege boundary involved, the kernel can never rely on
userspace code sign-extending arguments correctly.
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?
--
You are receiving this mail because:
You are on the CC list for the bug.