linux-kernel - APIC logic bug in kernel

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: <4F7B3D93.4030405@linux.intel.com>
Date:	Tue, 03 Apr 2012 19:12:35 +0100
From:	Bryan O'Donoghue <bryan.odonoghue@...ux.intel.com>
To:	linux-kernel@...r.kernel.org
Subject: APIC logic bug in kernel

Greetings list.

I'm looking at the code in arch/x86/kernel/apic/apic.c specifically the 
code path that checks for x86_vendor == X86_VENDOR_INTEL with 
boot_cpu_data.x86 = 5.

As I understand the code, BIOS will have informed kernel that it has an 
APIC based on mps tables. If the CPU family == 5, the function 
apic_verify() will be called.

Problem is apic_verify() does an rdmsr for an MSR that was not included 
in IA until P6.

Specifically rdmsr/wrmsr instructions in apic.c are not P5 compatible - 
since the MSR IA32_APIC_BASE was not introduced until P6_01 - as listed 
in the system programming guide volume 3.

Are all of these rdmsr/wrmsr calls made with an awareness of P5 ?

Example:

We check in apic_verify() if cpuid(1).edx has bit 9 (local APIC) set.
If so we set CPU capability FEATURE_APIC and rdmsr/wrmsr to 0x1B

arch/x86/include/asm/msr-index.h:#define MSR_IA32_APICBASE		0x0000001b

As I read this code it is perfectly valid for a P5, to have an APIC, 
report it has APIC capability via BIOS and CPUID and then subsequently 
to go ahead and touch the IA32_APIC_BASE MSR.

Basically this code doesn't seem to match the spec, am I missing a trick ?

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