[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/QZIVO...