linux-kernel - Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core

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:	Tue, 18 Sep 2012 22:30:15 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	John Stultz <john.stultz@...aro.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tony Luck <tony.luck@...el.com>,
	Paul Mackerras <paulus@...ba.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Paul Turner <pjt@...gle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding
 issue in timekeeping core

On Tue, Sep 18, 2012 at 9:50 PM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
>> I believe its mostly historical, but on some architectures that
>> history has become an established ABI, making it technical.
>
> Fine, but what do you mean by "ABI?" Are you talking about magic
> addresses for functions?
>
> Without knowing the dirty details, what I imagine is a jump/branch
> from the arch-specific code into the common implementation.

I suspect (based mostly on speculation) that this is possible for
everything except ia64.  ia64 looks like it uses a highly magical
syscall entry, where user code jumps to a special address for *all*
syscalls, and that code does some kind of partial kernel entry.  Very
careful asm code can run in that weird state, and that code implements
gettimeofday.  Now, if that code could return back to normal execution
and jump to a vdso, it could use common code, I guess.

This assumes that all architectures that want to use vclock_gettime,
etc are capable of sharing a page of read-only kernel memory with
userspace at a fixed address or can otherwise make the VVAR macro
work.  The only architectures I actually understand are x86-{32,64},
which can.  I don't think anyone cares about x86-32 enough to
implement it, though.

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