linux-kernel - Re: CPU hyperthreading turned on after soft power-cycle

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]

Date:	Mon, 28 Nov 2011 18:31:55 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Jiri Polach <clarinet@...as.cz>
Cc:	647095@...s.debian.org, Jonathan Nieder <jrnieder@...il.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: CPU hyperthreading turned on after soft power-cycle

On Mon, 2011-11-21 at 22:31 +0100, Jiri Polach wrote:
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index cb9a104..77b5273 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -640,7 +640,7 @@ config HPET_TIMER
> >   	  Choose N to continue using the legacy 8254 timer.
> >
> >   config HPET_EMULATE_RTC
> > -	def_bool y
> > +	def_bool n
> >   	depends on HPET_TIMER&&  (RTC=y || RTC=m || RTC_DRV_CMOS=m || RTC_DRV_CMOS=y)
> >
> >   config APB_TIMER
> 
> Applying this patch does not change anything, this kernel is "bad".

Using an older "known-good" kernel, could you build and run the test
case at the end of Documentation/rtc.txt a few times and see if it
triggers the same problem?

I'm suspicious that the setting the alarm is whats tripping the BIOS
into enabling the HT bit. Because with older kernels, we used PIE mode
irqs which hwclock usually uses at boot, but with newer kernels, we
emulate PIE via AIE alarm mode. So if the BIOS was broken before, you
wouldn't have noticed unless you tried to use AIE irqs.

If this doesn't work, I'll get some patches to both 2.6.27 and 2.6.28
kernels to debug the exact flow of how we're touching the hardware and
then we can further narrow it down.

thanks
-john

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