linux-kernel - Re: [PATCH] x86: clear incorrectly forced X86_FEATURE_LAHF

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Aug 2009 17:20:16 +0200
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Kevin Winchester <kjwinchester@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <yinghai@...nel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	LKML <linux-kernel@...r.kernel.org>, borislav.petkov@....com
Subject: Re: [PATCH] x86: clear incorrectly forced X86_FEATURE_LAHF_LM flag

Hi,

On Sat, Aug 08, 2009 at 08:53:30AM -0300, Kevin Winchester wrote:
> Due to an erratum with certain AMD Athlon 64 processors, the BIOS may
> need to force enable the LAHF_LM capability.  Unfortunately, in at
> least one case, the BIOS does this even for processors that do not
> support the functionality.
> 
> Add a specific check that will clear the feature bit for processors
> known not to support the LAHF/SAHF instructions.
> 
> Signed-off-by: Kevin Winchester <kjwinchester@...il.com>
> ---
> 
> While making this change, I noticed the clause above my code:
> 
>     if((level >= 0x0f48 && level < 0x0f50) || level >= 0x0f58)
> 
> It does not seem concerned with the possibility that some of the
> upper 16 bits of level will be non-zero.  Is this intentional, or
> should the upper 16 bits be masked off before the comparisons?

This should be ok because the upper 16 bits are 0x0000 for those
revisions and therefore the whole u32 matches. Later revisions have the
extended model bumped and they also match.

> 
>  arch/x86/kernel/cpu/amd.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index e2485b0..a2f0fe4 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -400,6 +400,14 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>  		level = cpuid_eax(1);
>  		if((level >= 0x0f48 && level < 0x0f50) || level >= 0x0f58)
>  			set_cpu_cap(c, X86_FEATURE_REP_GOOD);
> +
> +		/*
> +		 * Some BIOSes incorrectly set this feature, but only
> +		 * Revision E (with Extended Model = 2) actually supports
> +		 * it.
> +		 */
> +		if (!(level & 0x00020000))
> +			clear_cpu_cap(c, X86_FEATURE_LAHF_LM);

let me check this internally next week because
it seems that according to the Fam 0xf RevGuide
(http://support.amd.com/us/Processor_TechDocs/25759.pdf) erratum 110
applies to atleast 3 CPU revisions with extended model 0x1 too.

By the way, what does /proc/cpuinfo say on your machine?

-- 
Regards/Gruss,
    Boris.
--
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/