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]

Message-ID: <20080507064259.36deb978@infradead.org>
Date:	Wed, 7 May 2008 06:42:59 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Rene Herman <rene.herman@...access.nl>
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 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. 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.
--
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/