linux-kernel - Re: [PATCH] Re: x86_32 tsc/pit and hrtimers

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: <48EE8AB2.5000302@redhat.com>
Date:	Thu, 09 Oct 2008 18:50:26 -0400
From:	Chris Snook <csnook@...hat.com>
To:	akataria@...are.com
CC:	Alok kataria <alokkataria1@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jeff Hansen <x@...fhansen.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [PATCH] Re: x86_32 tsc/pit and hrtimers

Alok Kataria wrote:
> On Thu, 2008-10-09 at 14:03 -0700, Chris Snook wrote:
>> Alok kataria wrote:
>>> On Thu, Oct 9, 2008 at 12:53 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>>> On Thu, 9 Oct 2008, Jeff Hansen wrote:
>>>>
>>>>> OK, so are we all agreed that something like clocksource_trust=tsc would be
>>>>> the best?
>>>> No, it's per affected device: tsc=trust or tsc=stable or whatever
>>>> unintuitive name we want to come up. And it is a modification to TSC
>>>> not to the clocksource layer.
>>> Yep, this is cool. I too have a patch in my local tree which does a
>>> similar thing i have a tsc_reliable flag which is set right now only
>>> when we are running under a VMware hypervisor.
>>> Along with marking the no_verify flag for TSC, this patch of mine also
>>> skips the TSC synchornization checks.
>>>
>>>         The TSC synchronization loop which is run whenever a new cpu is
>>> brought up is not actually needed on systems which are known to have a
>>> reliable TSC. TSC between 2 cpus can be off by a marginal value on such
>>> systems and thats okay for timekeeping, since we do check for tsc going
>>> back in read_tsc.
>>>
>>> Can this reasoning be included and synchronization skipped for all
>>> these systems with reliable aka trustworthy TSC's  ?
>> In general, no.  Not all hardware/hypervisors behave this way, even when the TSC
>> is otherwise stable once synchronized.
> 
> I agree that in general this should be no, but since this is a
> commandline variable it will be normally set for only those systems
> which have only TSC as a option or know that the TSC is reliable.
> wouldn't doing this be ok for such systems ? 

Hardware doesn't deliberately do any TSC synchronization, though you might get 
it by accident in some configurations.  A VMware guest gets it for free thanks 
to the hypervisor doing it in software, but we need to run the check when we're 
booting on bare metal.  Jeff's patch enables the feature with as little risk as 
possible.  TSC sync is pretty cheap, so it's not worth it to add a more 
dangerous special case just for guests of certain hypervisors.

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