linux-kernel - Re: 2.6.26, PAT and AMD family 6

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:	Wed, 07 May 2008 16:09:05 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.26, PAT and AMD family 6

On 07-05-08 15:42, Arjan van de Ven wrote:
> On Wed, 07 May 2008 15:00:18 +0200
> Rene Herman <rene.herman@...access.nl> wrote:
> 
>> On 07-05-08 04:39, Yinghai Lu wrote:
>>
>>> On Tue, May 6, 2008 at 6:48 PM, Rene Herman
>>> <rene.herman@...access.nl> wrote:
>>>>  On 2.6.25 and below, my /proc/cpuinfo looks like:
>>>>
>>>>  processor       : 0
>>>>  vendor_id       : AuthenticAMD
>>>>  cpu family      : 6
>>>>  model           : 7
>>>>  model name      : AMD Duron(tm) Processor
>> [ ... ]
>>
>>>>  flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
>>>> mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
>>>>  while on current mainline PAT and TS (Temperature Sensor) drop
>>>> from the feature flags:
>>>>
>>>>  flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
>>>> mca cmov pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
>>>>
>>>>  With respect to PAT, I guess it's
>>>> 9307cacad0dfe3749f00303125c6f7f0523e5616, "x86: pat cpu feature
>>>> bit setting for known cpus" but what's this about?
>>>>
>>>> Did my cpuinfo lie upto this point or shouldn't the flag be
>>>> cleared? The commit message for that change is completely and
>>>> totally unhelpful.
>>> others like to to whitebox methods, ..., please try attach patch to
>>> see if duron support PAT.
>>> diff --git a/arch/x86/kernel/cpu/common.c
>>> b/arch/x86/kernel/cpu/common.c index a428ffc..81483ec 100644
>>> --- a/arch/x86/kernel/cpu/common.c
>>> +++ b/arch/x86/kernel/cpu/common.c
>>> @@ -314,6 +314,8 @@ static void __cpuinit early_get_cap(struct
>>> cpuinfo_x86 *c) case X86_VENDOR_AMD:
>>>  		if (c->x86 >= 0xf && c->x86 <= 0x11)
>>>  			set_cpu_cap(c, X86_FEATURE_PAT);
>>> +		if (c->x86 == 6 && c->x86_modes == 7)
>>> +			set_cpu_cap(c, X86_FEATURE_PAT);
>>>  		break;
>>>  	case X86_VENDOR_INTEL:
>>>  		if (c->x86 == 0xF || (c->x86 == 6 && c->x86_model
>>>> = 15))
>> s/modes/model/ but, as far as I'm aware, works fine other than that.
>> When I boot with CONFIG_X86_PAT after applying that, I see:
>>
>> 	x86 PAT enabled: cpu 0, old 0x7040600070406, new
>> 0x7010600070106
>>
>> and PAT is retained in the feature flags. However, this I do not
>> consider very surprising. Why is this code doing what it is doing in
>> the first place?
>>
>> These feature flags are read from hardware in the CPUID instruction.
>> Why is this code then going "ah, this CPU may _claim_ PAT but we
>> won't actually believe it unless it's model foo, bar or baz". Is that
>> feature flag buggy?
>>
> 
> older cpus had various issues with PAT, some blatently obvious, some
> more subtle.

And I suppose you have a list of these older CPUs or is this going to be
one of these things where in 5 years time I say to yet another person "ah
yes, I remember someone once telling me that old CPUs apparently had some
issues, some blatantly obvious, some more subtle" and the saga continues
on from there again?

> Since for old systems the mtrrs clearly work fine... the idea was to
> not take the risk (since there's no reward) and just leave them as
> is, in a working state.

With CONFIG_X86_PAT, you now see "CPU and/or kernel does not support PAT."
at the top of your dmesg which is going to make people wonder. I did a
cat /proc/cpuinfo, saw no PAT flag and was just suspicious enough that I
didn't trust it.

A blacklist would be a better idea I feel, but in ANY case I think it's
really bad form to clear the feature flag. They are provided by hardware;
if arch/x86/mm/pat.c won't risk running except on a select few tested
models, whatever, but my /proc/cpuinfo shouldn't be lying to me.

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