Bruce hacks:
> But there may be other ways to decompose the password, all based on the
> fact that fewer machine cycles will be needed to reject a password that's
> correct to fewer places. Interrupts and cache state changes will disrupt
> the timing to some extent, but there may still be enough timing
> information available over multiple trials to detect the difference --
> particularly on architectures with system-clock driven counters, like
> HP-PA.

Hence the PA-RISC 1.1 PSW register "S" bit, that, if turned on by the OS,
enables the Secure Interval Timer feature which prevents non-privileged
processes from reading the Interval Timer (Control Register 16) directly.

Normally CR16 can be read to get timing deltas with the same resolution
as the CPU clock rate, which enables you to determine how many instructions
got executed (or at least how many clock periods passed) between accesses.

Currently the only case I know of where the PSW S-bit is used is on HP-UX
if you enable the "secure system" mode.

Personally this seems like a silly thing to try to fix in hardware.  It
ought to be easier to write either constant time or random time comparison
routines.

G.