linux-kernel - Re: PIT clocksource makes invalid assumptions

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: <alpine.LFD.0.99999.0801041127570.4042@localhost.localdomain>
Date:	Fri, 4 Jan 2008 12:09:12 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dan Hecht <dhecht@...are.com>
cc:	Ingo Molnar <mingo@...e.hu>, john stultz <johnstul@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: PIT clocksource makes invalid assumptions

On Thu, 3 Jan 2008, Dan Hecht wrote:
> Seems these problems can happen when the PIT is used as the clocksource or
> even just the clocksource watchdog.  It looks like there is some code in
> clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for
> the PIT clocksource, but it doesn't seem to be strong enough to prevent these
> problematic scenarios (and it's not clear if that is the intent of
> IS_CONTINUOUS anyway).
>
> To verify this really can happen, when I boot a kernel, I can see this
> sequence:
> 
>   init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC)
>   init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED)
>   init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN)
>   pit_read() and count > LATCH (I believe the PIT is the watchdog at this
> point), which causes the PIT to raise periodic interrupts.

Darn, yes. This might happen on UP when we have local apic timer
available.

There is another caveat, when we have HPET and enable it.

> (Shortly after, the acpi pm clocksource is registered and replaces the PIT as
> the watchdog.  Later, the PIT clockevent is used as the broadcast clockevent
> and reprogrammed into one-shot mode, stopping the PIT interrupts.)
> 
> Also, the user could force the PIT clocksource to be current_clocksource even
> though the PIT is in one-shot mode (and therefore the calculation in pit_read
> is bogus).

Yup, we need to prevent that.

> Of course, all this can only happen for 32-bit UP.  I'm not sure what the
> preferred fix for this is...

I guess disabling PIT clocksource there is the way to go. Not sure
yet, need to look into all the odds and ends.

Thanks for pointing this out,

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