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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <49C11403.6010305@windriver.com>
Date:	Wed, 18 Mar 2009 11:32:19 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Clemens Ladisch <clemens@...isch.de>
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)

Clemens Ladisch wrote:
> 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.
>   

Right - as I said, I didn't expect that it could ever happen, and your 
analysis
above seems to help reinforce that, so we probably should be OK.

Thanks,
Paul.

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