linux-kernel - 2.6.26-rc1 lies about PAT not being available

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-next>] [day] [month] [year] [list]

Message-ID: <18464.5177.649312.999486@harpo.it.uu.se>
Date:	Tue, 6 May 2008 10:18:01 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	venkatesh.pallipadi@...el.com
Cc:	linux-kernel@...r.kernel.org
Subject: 2.6.26-rc1 lies about PAT not being available

Booting 2.6.26-rc1 on an old Coppermine PIII, I'm greeted with:

>Linux version 2.6.26-rc1 (mikpe@...hop) (gcc version 4.2.3) #1 Mon May 5 21:49:49 CEST 2008
>BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
> BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000002ffec000 (usable)
> BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data)
> BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved)
> BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
>CPU and/or kernel does not support PAT.

I know about Intel's PAT erratum (only 4 PAT entries work) and
understand that the kernel might not want to use a half-broken
PAT implementation, but the statement above is blatantly false:
the kernel IS built with PAT support and the CPU DOES have
(half-broken) PAT HW support as /proc/cpuinfo from earlier kernels
confirms.

arch/x86/kernel/cpu/common.c unconditionally disables PAT and
then reenables it for certain vendor/family/model combinations.(*)
Then mm/pat.c comes along, finds !cpu_has_pat, and prints the
bogus message above.

IMO, it would be a lot nicer if common.c printed a warning when
it disables PAT due to the erratum, then the printk() in pat.c
could be something like "PAT support absent or disabled".

(*) common.c enables PAT for all Intel family 15 CPUs. Is that
correct? I don't have the spec updates in front of me, but I
seem to recall the PAT erratum existed also in early P4s.

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