linux-kernel - Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

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:	Tue, 10 May 2011 13:58:59 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Greg KH <gregkh@...e.de>, Hans Rosenfeld <hans.rosenfeld@....com>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	akpm@...ux-foundation.org, "H. Peter Anvin" <hpa@...ux.intel.com>,
	torvalds@...ux-foundation.org, stable-review@...nel.org,
	alan@...rguk.ukuu.org.uk, bp@...64.org
Subject: Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400
 workaround

On Fri, 2011-05-06 at 09:41 +0200, Borislav Petkov wrote:
> Hey Ben,
> 
> On Thu, May 05, 2011 at 03:53:02PM -0700, Greg KH wrote:
> > On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
> > > > We got a few new quirks added for AMD hardware platforms that fix
> > > > problems.
> > > 
> > > Maybe, but I still haven't seen anyone explain what those problems are!
> > 
> > I'll let the AMD people answer this.
> 
> it's hard to follow back in this thread to what exactly you'd like to
> have answered. Can you please repeat your questions concerning the AMD
> backports? Is it, per chance, about Erratum 400 CPU f/m/s ranges that
> got changed?

I read that:

"
    Support for Always Running APIC timer (ARAT) was introduced in
    commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
    allows us to avoid switching timers from LAPIC to something else
    (e.g. HPET) and go into timer broadcasts when entering deep
    C-states.
    
    AMD processors don't provide a CPUID bit for that feature but
    they also keep APIC timers running in deep C-states (except for
    cases when the processor is affected by erratum 400). Therefore
    we should set ARAT feature bit on AMD CPUs.
"

This implies that the HPET was previously used during deep C-states, and
that all this erratum checking is about deciding whether the CPU has
ARAT.  So what bug is being fixed by using ARAT instead of the HPET?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)