linux-kernel - Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation

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]

Message-ID: <4AF274E5.5080205@redhat.com>
Date:	Thu, 05 Nov 2009 08:47:01 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Glauber Costa <glommer@...hat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	kurt.hackel@...cle.com, the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Glauber de Oliveira Costa <gcosta@...hat.com>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Keir Fraser <keir.fraser@...citrix.com>, zach.brown@...cle.com,
	chris.mason@...cle.com, Ingo Molnar <mingo@...hat.com>
Subject: Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall	implementation

On 11/04/2009 10:30 PM, Dan Magenheimer wrote:
>>
>> In this case we should provide a facility for this.
>> Providing a global
>> monotonic counter may be easier than providing a monotonic
>> clock.  Hence
>> my question.
>>      
> Maybe I'm misunderstanding something, but enterprise
> apps can do this entirely on their own without any
> kernel help, correct?
>    

Within a process, yes.  Across processes, not without writable shared 
memory.

That's why I'm trying to understand what the actual requirements are.  
Real monotonic, accurate, high resolution, low cost time sources are 
hard to come by.

>> I doubt it.  A discontinuity has occured, but what do we know
>> about it? nothing.
>>      
> Actually, I think for many/most profiling applications,
> just knowing a discontinuity occurred between two
> timestamps is very useful as that one specific measurement
> can be discarded.  If a discontinuity is invisible,
> one clearly knows that a negative interval is bad,
> but if an interval is very small or very large,
> one never knows if it is due to a discontinuity or
> due to some other reason.
>
> This would argue for a syscall/vsyscall that can
> "return" two values: the "time" and a second
> "continuity generation" counter.
>
>    

I doubt it.  You should expect discontinuities in user space due to 
being swapped out, scheduled out, migrated to a different cpu, or your 
laptop lid being closed.  There are no guarantees to a userspace 
application.  Even the kernel can expect discontinuities due to SMIs.  
So an explicit notification about one type of discontinuity adds nothing.

>>> True, though clock_gettime(CLOCK_MONOTONIC) can provide
>>> the monotonicity where it is required.
>>>        
>> We have that already.  The question is how to implement it in
>> a vsyscall.
>>      
> Oh, I see.  I missed that very crucial point.
>
> So, just to verify/clarify... There is NO WAY for
> a vsyscall to ensure monotonicity (presumably because
> the previous reading can't be safely stored?).  So
> speed and "correctness" are mutually exclusive?
>    

Yes.

> If true, yes, that's a potentially significant problem\
> though an intelligent app can layer monotonicity
> on top of the call I suppose.
>    

Unless it's a multi-process app with limited trust.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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