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:	Thu, 20 Dec 2007 03:51:04 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	mtk.manpages@...glemail.com
Cc:	akpm@...ux-foundation.org, lkml@...idb.org, paulus@...ba.org,
	drepper@...hat.com, cfriesen@...tel.com, schwab@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: compat_sys_times() bogus until jiffies >= 0.

From: Michael Kerrisk <mtk.manpages@...glemail.com>
Date: Thu, 20 Dec 2007 12:36:52 +0100

> Some testing just now shows me that lseek() on /dev/mem suffers similar
> problems when seeking to bytes 0xfffff001 through to 0xffffffff.

Only on x86 platforms.  Sparc, IA64, MIPS, powerpc, etc. all get this
case right.

Yes it's another unfortunate side effect of how error status is
indicated for x86 system calls.

I would suggest, that we put something in place to fix this
in the long term:

1) Start setting the condition codes properly to indicate
   error in the system call return path on x86 like other
   platforms do now.  Make sure that it tips off on
   force_successful_syscall_return(), as needed.

2) Come up with a transition plan for glibc et al. to take
   advantage of this.

It actually sounds like the kind of problem that could be
solved well using the VDSO page. :-)

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