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
| ||
|
Date: 10 Jun 2015 12:11:57 -0400 From: "George Spelvin" <linux@...izon.com> To: adrian.hunter@...el.com, mingo@...nel.org Cc: ak@...ux.intel.com, hpa@...or.com, linux-kernel@...r.kernel.org, linux@...izon.com, luto@...capital.net, tglx@...utronix.de, torvalds@...ux-foundation.org Subject: Re: Discussion: quick_pit_calibrate is slow > Especially any 'measure the minimum time' approach measuring more than > a single PIT tick would be senstive to false positives. Just to be clear, I'm not measuring the minimum of any timer ticks; it's the timer *access* that's being measured. It's literally the duration of a single inb() or outb(). Even the *value* is unimportant. It's just a way to figure out the skew between the TSC and the peripheral. Think of the peripheral access like a network ping. I'm asking a remote computer for its time, and measuring *my* time at the start and end of the ping. There's a minimum possible ping time, achieved where queueing delays are zero. If I could achieve that minimum time reliably, synchronizing clocks rates would be trivial. To measure offset, I have to make some arbitrary assumption about the duration of the two legs of the round trip. Typically I assume that they're equal, so that the remote time corresponds to the point halfway between my two time measurements. (For timer rate measurements, it turns out that this assumption doesn't affect the result at all, so it can be made arbitrarily.) If a ping takes more than the minimum possible time, then what's actually most likely is that *one* of the two legs was delayed, and the correct time is not in the middle of the ping time range, but hard up against one edge. I.e. t1 = get_cycles(); byte = inb(peripheral); t2 = get_cycles(); interval = t2 - t1; tmin = min(interval, tmin); The instant of the inb() is most likely t1 + tmin/2, or t2 - tmin/2, might be elsewhere in that interval, but is definitely not (if tmin has been measured accurately) outside that interval. -- 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/
Powered by blists - more mailing lists