linux-kernel - [tip:x86/urgent] x86, hpet: Fix bug in RTC emulation

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>] [day] [month] [year] [list]

Date:	Thu, 1 Apr 2010 22:58:33 GMT
From:	tip-bot for Alok Kataria <akataria@...are.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	dhecht@...are.com, linux-kernel@...r.kernel.org, hpa@...or.com,
	mingo@...hat.com, akpm@...ux-foundation.org,
	venkatesh.pallipadi@...il.com, akataria@...are.com,
	tglx@...utronix.de, mingo@...e.hu
Subject: [tip:x86/urgent] x86, hpet: Fix bug in RTC emulation

Commit-ID:  b4a5e8a1deca7e61ebaffb37344766b0f0e9f327
Gitweb:     http://git.kernel.org/tip/b4a5e8a1deca7e61ebaffb37344766b0f0e9f327
Author:     Alok Kataria <akataria@...are.com>
AuthorDate: Thu, 11 Mar 2010 14:00:16 -0800
Committer:  H. Peter Anvin <hpa@...or.com>
CommitDate: Thu, 1 Apr 2010 15:21:48 -0700

x86, hpet: Fix bug in RTC emulation

We think there exists a bug in the HPET code that emulates the RTC.

In the normal case, when the RTC frequency is set, the rtc driver tells
the hpet code about it here:

int hpet_set_periodic_freq(unsigned long freq)
{
        uint64_t clc;

        if (!is_hpet_enabled())
                return 0;

        if (freq <= DEFAULT_RTC_INT_FREQ)
                hpet_pie_limit = DEFAULT_RTC_INT_FREQ / freq;
        else {
                clc = (uint64_t) hpet_clockevent.mult * NSEC_PER_SEC;
                do_div(clc, freq);
                clc >>= hpet_clockevent.shift;
                hpet_pie_delta = (unsigned long) clc;
        }
        return 1;
}

If freq is set to 64Hz (DEFAULT_RTC_INT_FREQ) or lower, then
hpet_pie_limit (a static) is set to non-zero.  Then, on every one-shot
HPET interrupt, hpet_rtc_timer_reinit is called to compute the next
timeout.  Well, that function has this logic:

        if (!(hpet_rtc_flags & RTC_PIE) || hpet_pie_limit)
                delta = hpet_default_delta;
        else
                delta = hpet_pie_delta;

Since hpet_pie_limit is not 0, hpet_default_delta is used.  That
corresponds to 64Hz.

Now, if you set a different rtc frequency, you'll take the else path
through hpet_set_periodic_freq, but unfortunately no one resets
hpet_pie_limit back to 0.

Boom....now you are stuck with 64Hz RTC interrupts forever.

The patch below just resets the hpet_pie_limit value when requested freq
is greater than DEFAULT_RTC_INT_FREQ, which we think fixes this problem.

Signed-off-by: Alok N Kataria <akataria@...are.com>
LKML-Reference: <201003112200.o2BM0Hre012875@...p1.linux-foundation.org>
Signed-off-by: Daniel Hecht <dhecht@...are.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@...or.com>
---
 arch/x86/kernel/hpet.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3d422da..2bda5f0 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -1149,6 +1149,7 @@ int hpet_set_periodic_freq(unsigned long freq)
 		do_div(clc, freq);
 		clc >>= hpet_clockevent.shift;
 		hpet_pie_delta = clc;
+		hpet_pie_limit = 0;
 	}
 	return 1;
 }
--
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/