| 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
| ||
|
Message-ID: <f7f07e9e-010c-68d9-77c2-16bde71a0eb8@molgen.mpg.de>
Date: Wed, 2 Oct 2019 17:52:36 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Thomas Lendacky <Thomas.Lendacky@....com>,
Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Jiri Kosina <jikos@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Kinky Nekoboi <kinky_nekoboi@...oboi.moe>,
Merlin Büge <toni@...enox07.de>,
Timothy Pearson <tpearson@...torengineering.com>,
Vikings GmbH <hello@...ings.net>,
Piotr Król <piotr.krol@...eb.com>,
coreboot@...eboot.org
Subject: Re: General protection fault in `switch_mm_irqs_off()`
[CC: +affected coreboot folks, +coreboot mailing list]
Dear Thomas,
More affected people discussed this issue on the coreboot mailing list [1].
On 2019-01-14 18:37, Lendacky, Thomas wrote:
> On 1/14/19 11:09 AM, Paul Menzel wrote:
>> On 01/14/19 18:00, Lendacky, Thomas wrote:
>>> On 1/10/19 12:34 PM, Lendacky, Thomas wrote:
>>>> On 1/10/19 10:49 AM, Paul Menzel wrote:
>>>>> Dear Boris, dear Thomas,
>>>>>
>>>>>
>>>>> On 01/10/19 17:00, Borislav Petkov wrote:
>>>>>> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote:
>>>>>>> Thank you very much. Indeed, the machine does not crash. I used Linus’
>>>>>>> master branch for testing, and applied your patch on top. Please find
>>>>>>> the full log attached.
>>>>>>
>>>>>>> 80.649: [ 3.197107] Spectre V2 : spectre_v2_user_select_mitigation: set X86_FEATURE_USE_IBPB
>>>>>>
>>>>>> This is amazing.
>>>>>>
>>>>>> Ok, next diff, same exercise. Thx.>
>>>>>> ---
>>>>>> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
>>>>>> index dad12b767ba0..528ef8336f5f 100644
>>>>>> --- a/arch/x86/include/asm/nospec-branch.h
>>>>>> +++ b/arch/x86/include/asm/nospec-branch.h
>>>>>> @@ -284,6 +284,12 @@ static inline void indirect_branch_prediction_barrier(void)
>>>>>> {
>>>>>> u64 val = PRED_CMD_IBPB;
>>>>>>
>>>>>> + if (WARN_ON(boot_cpu_has(X86_FEATURE_USE_IBPB))) {
>>>>>> + pr_info("%s: c: %px, array: 0x%x\n",
>>>>>> + __func__, &boot_cpu_data, boot_cpu_data.x86_capability[7]);
>>>>>> + return;
>>>>>> + }
>>>>>> +
>>>>>> alternative_msr_write(MSR_IA32_PRED_CMD, val, X86_FEATURE_USE_IBPB);
>>>>>> }
>>>>>>
>>>>>> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
>>>>>> index 8654b8b0c848..e818e5abe611 100644
>>>>>> --- a/arch/x86/kernel/cpu/bugs.c
>>>>>> +++ b/arch/x86/kernel/cpu/bugs.c
>>>>>> @@ -371,6 +371,9 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd)
>>>>>> if (boot_cpu_has(X86_FEATURE_IBPB)) {
>>>>>> setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
>>>>>>
>>>>>> + pr_err("%s: set X86_FEATURE_USE_IBPB, c: %px, array: 0x%x\n",
>>>>>> + __func__, &boot_cpu_data, boot_cpu_data.x86_capability[7]);
>>>>>> +
>>>>>> switch (cmd) {
>>>>>> case SPECTRE_V2_USER_CMD_FORCE:
>>>>>> case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
>>>>>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>>>>>> index cb28e98a0659..8566737fa500 100644
>>>>>> --- a/arch/x86/kernel/cpu/common.c
>>>>>> +++ b/arch/x86/kernel/cpu/common.c
>>>>>> @@ -765,6 +765,9 @@ static void apply_forced_caps(struct cpuinfo_x86 *c)
>>>>>> c->x86_capability[i] &= ~cpu_caps_cleared[i];
>>>>>> c->x86_capability[i] |= cpu_caps_set[i];
>>>>>> }
>>>>>> +
>>>>>> + if (c == &boot_cpu_data)
>>>>>> + pr_info("%s: c: %px, array: 0x%x\n", __func__, c, c->x86_capability[7]);
>>>>>> }
>>>>>>
>>>>>> static void init_speculation_control(struct cpuinfo_x86 *c)
>>>>>> @@ -778,6 +781,10 @@ static void init_speculation_control(struct cpuinfo_x86 *c)
>>>>>> if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) {
>>>>>> set_cpu_cap(c, X86_FEATURE_IBRS);
>>>>>> set_cpu_cap(c, X86_FEATURE_IBPB);
>>>>>> +
>>>>>> + pr_info("%s: X86_FEATURE_SPEC_CTRL: c: %px, array: 0x%x, CPUID: 0x%x\n",
>>>>>> + __func__, c, c->x86_capability[7], cpuid_edx(7));
>>>>>> +
>>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>>>>>> }
>>>>>>
>>>>>> @@ -793,9 +800,13 @@ static void init_speculation_control(struct cpuinfo_x86 *c)
>>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>>>>>> }
>>>>>>
>>>>>> - if (cpu_has(c, X86_FEATURE_AMD_IBPB))
>>>>>> + if (cpu_has(c, X86_FEATURE_AMD_IBPB)) {
>>>>>> set_cpu_cap(c, X86_FEATURE_IBPB);
>>>>>>
>>>>>> + pr_info("%s: X86_FEATURE_AMD_IBPB: c: %px, array: 0x%x, CPUID: 0x%x\n",
>>>>>> + __func__, c, c->x86_capability[7], cpuid_ebx(0x80000008));
>>>>>> + }
>>>>>> +
>>>>>> if (cpu_has(c, X86_FEATURE_AMD_STIBP)) {
>>>>>> set_cpu_cap(c, X86_FEATURE_STIBP);
>>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
>>>>>
>>>>> Please find the logs attached.
>>>>
>>>> Ah, so the CPUID value is showing X86_FEATURE_AMD_IBPB (not sure why the
>>>> cpuid command was showing a value of zero for EBX in your previous email).
>>>> Let me see what I can find out about this processor/firmware relation. I
>>>> wouldn't expect to see the #GP given that the firmware says IBPB is
>>>> supported.
>>>
>>> I'm not able to reproduce this issue on my family 21, model 1, stepping 2
>>> processor (AMD Opteron(TM) Processor 6274) as I am able to successfully
>>> write to the PRED_CMD MSR.
>>
>> It’s not exactly the same processor, but I guess the same family should be
>> good enough. What board do you have? Do you have two sockets, and both
>> populated?
>
> Yes, It is a two-socket system with two processors installed.
>
>> Here is an Asus KGPE-D16 with two AMD Opterons put in.
>>
>> Lastly, my microcode updates are applied in firmware, and not by GNU/Linux.
>
> Ok, I was confused on how you had reported that, sorry.
Kinky reports, that populating the memory slots of both NUMA nodes fixes this.
Kinky, what slots do you have exactly populated?
I haven’t been able to verify that yet, but please find my output of
`sudo dmidecode -t memory` with a 8 * 16 GB system attached, which is
affected.
> Can we try an experiment where you use the older version of the Asus
> firmware but build an initramfs that will perform early microcode loading?
> I'm curious if things will work when loaded via Linux.
I believe the users reported that this works.
>>> Let's check the firmware file that you're loading. The one I'm using is:
>>>
>>> $ sha1sum /lib/firmware/amd-ucode/microcode_amd_fam15h.bin
>>> 90896256951d8edf7baf8181ae11e2dc618a5171 /lib/firmware/amd-ucode/microcode_amd_fam15h.bin
>>>
>>> Does that match what you have?
>>
>> Yes, that matches exactly.
>>
>> 90896256951d8edf7baf8181ae11e2dc618a5171 3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin
Kind regards,
Paul
[1]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/QZIVOD4UADLLPZEE7MFUUTQQM343GKOC/
View attachment "asus-kgpe-d16-128-gb-dmidecode-t-memory.txt" of type "text/plain" (4779 bytes)
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5174 bytes)
Powered by blists - more mailing lists