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 Nov 2015 13:47:24 -0600
From:	Gratian Crisan <gratian.crisan@...com>
To:	Josh Hunt <joshhunt00@...il.com>
CC:	Peter Zijlstra <peterz@...radead.org>, <gratian.crisan@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H . Peter Anvin" <hpa@...or.com>, <x86@...nel.org>,
	Borislav Petkov <bp@...en8.de>, Josh Cartwright <joshc@...com>,
	<gratian@...il.com>
Subject: Re: [RFC PATCH] tsc: synchronize TSCs on buggy Intel Xeon E5 CPUs with offset error


Josh Hunt writes:

> On Tue, Nov 10, 2015 at 12:24 PM, Josh Hunt <joshhunt00@...il.com> wrote:
>>
>> On Mon, Nov 9, 2015 at 4:02 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>>>
>>> On Mon, Nov 09, 2015 at 01:59:02PM -0600, gratian.crisan@...com wrote:
>>>
>>> > The Intel Xeon E5 processor family suffers from errata[1] BT81:
>>>
>>> > +#ifdef CONFIG_X86_TSC
>>> > +     /*
>>> > +      * Xeon E5 BT81 errata: TSC is not affected by warm reset.
>>> > +      * The TSC registers for CPUs other than CPU0 are not cleared by a warm
>>> > +      * reset resulting in a constant offset error.
>>> > +      */
>>> > +     if ((c->x86 == 6) && (c->x86_model == 0x3f))
>>> > +             set_cpu_bug(c, X86_BUG_TSC_OFFSET);
>>> > +#endif
>>>
>>> That's hardly a family, that's just one, Haswell server.
>>
>>
>> Are you actually observing this problem on this processor?
>>
>> The document you've referenced and the x86_model # above do not match up. The errata should be for Intel processors with an x86_model value of 0x2d by my calculations:
>>
>> Model: 1101b
>> Extended Model: 0010b
>>
>> The calc from cpu_detect() is:
>>                  if (c->x86 >= 0x6)
>>                         c->x86_model += ((tfms >> 16) & 0xf) << 4;
>>
>> 0x3f is a different CPU.

The processor I am seeing the issue on is (according to /proc/cpuinfo):
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2618L v3 @ 2.30GHz
stepping	: 2
microcode	: 0x2e

The observed behavior does seem to match BT81 errata i.e. the TSC does
not get reset on warm reboots and it is otherwise stable.

However you are correct in pointing out that the errata CPU model number
does not match. My apologies, decoding the x86 cpu info/model numbers is
a new area for me and the title of the errata made it sound like it
applies to the whole Intel Xeon E5 family. It was only in trying to
reply to Peter's comment that I've noticed the discrepancy with regards
to the model number.

I am currently trying to figure out if there is an errata that
specifically lists Xeon E5-2618L with TSC problems on warm resets and I
will re-work this.

Sorry again for not double checking.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ