linux-kernel - Re: [Patch] Fix the possibility of insane return value of hpet

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49C10F1B.9050809@ladisch.de>
Date:	Wed, 18 Mar 2009 16:11:23 +0100
From:	Clemens Ladisch <clemens@...isch.de>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
CC:	Yasunori Goto <y-goto@...fujitsu.com>,
	Linux Kernel ML <linux-kernel@...r.kernel.org>,
	robert.picco@...com, venkatesh.pallipadi@...el.com,
	vojtech@...e.cz, mingo@...hat.com
Subject: Re: [Patch] Fix the possibility of insane return value of hpet_calibrate()
 against SMI. (take 2)

Paul Gortmaker wrote:
> Yasunori Goto wrote:
> > +	/*
> > +	 * Try to calibrate until return value becomes stable small value.
> > +	 * If SMI interruption occurs in calibration loop, the return value
> > +	 * will be big. This avoids its impact.
> > +	 */
> > +	do {
> > +		tmp = __hpet_calibrate(hpetp);
> > +		if (ret <= tmp)
> > +			break;
> > +		ret = tmp;
> > +	} while (1);
> 
> For what it is worth, if a situation arose where continued calls to
> hpet_calibrate() represented a monotonically decreasing function,
> (perhaps some insane power management?) you could be stuck
> in this function for an unbounded amount of time.

On my machine, the number of iterations of the loop in __hpet_calibarate
(the value of i) is about 400, and since HPET reads/writes go to the
southbridge, it cannot get much higher than about 1000 even on faster
machines.

The value of (m - start) is approximately constant, as long as the loop
runs for about 1 ms, so there cannot be too many distinct return values.

Consequently, the only way for perverse SMIs to produce more
monotonically decreasing calibration values is to introduce delays that
make the loop run longer than 1 ms, i.e., to eat most of the CPU time
for at least several seconds (or longer if you want unbounded time).
Even in the real world ;-), no laptop manufacturer is that insane.

Best regards,
Clemens
--
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/