linux-kernel - Re: [RFC 1/2] time: workaround crappy 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] [day] [month] [year] [list]

Date:	Mon, 18 Apr 2016 10:54:58 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Shaohua Li <shli@...com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>, calvinowens@...com
Subject: Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:48 AM, Shaohua Li <shli@...com> wrote:
> On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote:
>> I'm sort of on the edge of just adding a blacklist entry for the HPET
>> on this hardware. I'm not sure its something that can be easily
>> handled generically.   I *hope* you only see this issue on one sort of
>> hardware?
>
> Blacklist is a option for sure. We saw the issue in several machines,
> but seems they are the same type. I hope we can have a defensive way to
> handle such problem if it happens in other hardware.

Yea. I'm not sure what can be done. Filtering -1 values from the HPET
seems problematic for latency reasons. I'm not sure we should punish
all the fine hardware w/o the issue just to try to detect the case
where its bad.

Especially as this is something particularly problematic to detect
separately from other more common well known bad hardware.

thanks
-john