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>] [day] [month] [year] [list]
Date:	Thu, 06 Aug 2009 13:50:46 -0300
From:	Kevin Winchester <kjwinchester@...il.com>
To:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: X86_FEATURE_LAHF_LM set incorrectly (likely due to BIOS bug)


Hi,

I have an AMD Athlon64 processor:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 4
model name	: AMD Athlon(tm) 64 Processor 2800+
stepping	: 10
cpu MHz		: 1800.000
cache size	: 512 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good lahf_lm
bogomips	: 3600.25
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

As you can see, the lahf_lm feature is reported as being present,
but the lahf/sahf instructions are not actually supported by this
processor.  A simple program:

int main() {
	asm("lahf");
}


results in:

$ ./a.out
Illegal instruction

I think the problem is with my BIOS, because, in the following guide
from AMD:

http://support.amd.com/us/Processor_TechDocs/25759.pdf

Erratum 110 indicates that some CPUs will not report the LAHF
capability, even if they have it, and the BIOS should write to a
specific MSR bit in order to get the feature reported as present (for
processors that support LAHF).  I believe that perhaps my BIOS is
writing to that bit unconditionally, and this causes my CPU to report
support for the feature.

If I am correct, would it be appropriate to add a check somewhere in
the CPU feature code to detect early Athlon 64 processors like mine
and clear that feature flag, in case other BIOSes have made the same
mistake?  If so, is there some kind of quirk mechanism for this, or
should I prepare a patch that adds the check directly to the feature
checking code?

Thanks,

-- 
Kevin Winchester

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ