linux-kernel - Re: compat_sys_times() bogus until jiffies >= 0.

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:	Wed, 07 Nov 2007 19:13:54 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	paulus@...ba.org, lkml@...idb.org, linux-kernel@...r.kernel.org,
	drepper@...hat.com, mtk-manpages@....net
Subject: Re: compat_sys_times() bogus until jiffies >= 0.

From: Andrew Morton <akpm@...ux-foundation.org>
Date: Wed, 7 Nov 2007 19:07:14 -0800

> It appears that glibc treats all of 0x80000000-0xffffffff as an
> error.

glibc treats it as an error if the system call returns with
the carry condition code set.  At least that's how I've
understood it to work and at a minimum this is how it works
on sparc, ppc, ia64, mips, etc.

The error indication is being created by the system call return path
in the kernel.  It tests for values between -512 and 0, and marks
those as errors unless force_successful_syscall() has been called.

I can't see where x86 is doing this though, so perhaps for x86
glibc does make the negative value check.  But I doubt it is
checking the range 0x80000000-0xffffffff, otherwise mmap() would
be busted.

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