This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/18726] Futexes are broken on MIPS/n32


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]