linux-kernel - Re: [PATCH v3] 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:	Tue, 11 Aug 2009 21:15:50 -0300
From:	Kevin Winchester <kjwinchester@...il.com>
To:	Borislav Petkov <borislav.petkov@....com>
CC:	Mikael Pettersson <mikpe@...uu.se>,
	Borislav Petkov <petkovbb@...glemail.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] x86: clear incorrectly forced X86_FEATURE_LAHF_LM
 flag

Borislav Petkov wrote:
> On Tue, Aug 11, 2009 at 12:55:03PM -0300, Kevin Winchester wrote:
>> 2009/8/11 Borislav Petkov <borislav.petkov@....com>:
>>> On Tue, Aug 11, 2009 at 04:37:56PM +0200, Mikael Pettersson wrote:
>>>> Since the BIOS apparently wrote some MSR to get LAHF_LM incorrectly
>>>> reported by CPUID, would it be possible to also correct that MSR so
>>>> that applications that execute CPUID get the correct feature flags?
>>> That's a good catch, actually. We have to turn off that bit in the cpuid
>>> leaf too if the CPU doesn't support the instructions so that cpuid info
>>> is consistent. LAHF/SAHF support in 64bit mode has to be cpuid-checked
>>> prior to using them so that info has to be correct.
>>>
>>> @Kevin: willing to try a patch or two?
>>>
>> Sure, I'll give it a try this evening.  I assume that since Erratum 110 says:
>>
>> --------------------------
>> Suggested Workaround
>> For processors which support the feature (as determined by the
>> processor revision ID), BIOS should
>> write a one to:
>> • MSR C001_100Dh, bit 32 for revision D silicon.
>> • MSR C001_1005h, bit 32 for revision E and later silicon.
>> This will cause the extended feature flag in ECX[0] to be set.
>> --------------------------
>>
>> That writing a zero to those same MSRs would clear the feature flag?
> 
> Yep :). Patch coming up...
> 

I have been attempting to read those MSRs through the /dev/cpu/0/msr device
file, without any success.  Is it possible that my CPU will not have those
MSRs?  And if so, then maybe my original assumption about the BIOS forcing
on the LAHF_LM feature is wrong.

In any case, clearing the feature flag (and thus fixing /proc/cpuinfo) is
still the right thing to do.

Do you have any other suggestions for how I would affect that CPUID flag?

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