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: <4821FE2E.9030606@keyaccess.nl>
Date:	Wed, 07 May 2008 21:08:30 +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 16:24, Arjan van de Ven wrote:

> On Wed, 07 May 2008 16:09:05 +0200
> Rene Herman <rene.herman@...access.nl> wrote:

> [as for which cpus]
> 
> The errata docs have these errata, at least for Intel I know they're
> there. We can add back older cpus over time, but again.. think of it as
> a risk/reward thing ;( Right now, breaking all kinds of well working
> older systems without benefits on the upside.....

What/who do you break, when they are not selecting CONFIG_X86_PAT? The
help text can be suitably alarming. I feel this is no argument at all.

> that's not very popular on lkml. Once PAT is rock solid I hope we can
> relax this check greatly...

A blacklist would seem to be really much preferred. All of AMD family 6
has been excluded in one fell swoop now for example, while I sort of
expect not any of them should be.

>> 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.
> 
> we filter those for all kinds of things already, sorry.
> What good is showing "pat" if "pat" isn't deemed usable (yet)????
> Now *that* is deception :)

The trouble is -- if you hide that the CPU _should_ have PAT, how many
people do you expect are going to look further and test? I knew that I
should have PAT so I distrusted my CPU feature flag display but you've
now limited your testers to people who've read the CPU datasheet.
That's really no good.

If Linux messes around with those flags already, it's doing things
wrong already. /proc/cpuinfo is not a display of software features
but of hardware features -- anything else is outright wrong. Being
wrong for PAT also doesn't improve things.

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/