KGPE-d16 recent microcode (Adds IBPB) produces kernel panics

[Kinky Nekoboi]

loading the microcode via Linux Kernel works.

including it via coreboot causes General Protection Faults.

See included bootlog.

[Paul Menzel]

Dear Kinky,

On 7/30/19 11:18 AM, Kinky Nekoboi wrote:
> loading the microcode via Linux Kernel works.
>
> including it via coreboot causes General Protection Faults.
>
> See included bootlog.

We hit the same issue on our board, and reported it to the Linux kernel
developers [1].

Unfortunately, we didn’t have more resources to pursue this further.

1.  What is your configuration? How many processors, how much RAM?

2.  So, loading it from GNU/Linux (initramfs) as Tom asked, seems to
    work. I guess it’s the same with the vendor firmware?

3.  As Tom tested it on a similar custom AMD board (with supposedly
    microcode updates updated in the *vendor firmware*, and it worked
    for him, there might be something wrong with how microcode updates
    are applied in coreboot.

4.  The user *sfs* in #[e-mail] did not have the
    problems if I remember correctly.

Anyway, somebody with time and motivation would need to debug this. But
it’d be great if you could check a few things and maybe chime in the
LKML discussion.

Kind regards,

Paul

[1]: https://lkml.org/lkml/2019/1/3/540
     "General protection fault in `switch_mm_irqs_off()`"

[Kinky Nekoboi]

Hello Paul,

mein Configuration is:

1x Opteron 6380

processor    : 15
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 2
model name    : AMD Opteron(tm) Processor 6380

and MEM:

root@lain:~# dmidecode -t 17
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x000B, DMI type 17, 40 bytes
Memory Device
    Array Handle: 0x000A
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: DIMM
    Set: None
    Locator: NODE 0 DIMM_C2
    Bank Locator: Not Specified
    Type: DDR3
    Type Detail: Synchronous Registered (Buffered)
    Speed: 667 MT/s
    Manufacturer: Samsung
    Serial Number: 7926BB85
    Asset Tag: Not Specified
    Part Number: M393B1K70DH0-CH9 
    Rank: 2
    Configured Memory Speed: 667 MT/s
    Minimum Voltage: 1.5 V
    Maximum Voltage: 1.5 V
    Configured Voltage: 1.5 V

Handle 0x000C, DMI type 17, 40 bytes
Memory Device
    Array Handle: 0x000A
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: DIMM
    Set: None
    Locator: NODE 0 DIMM_D2
    Bank Locator: Not Specified
    Type: DDR3
    Type Detail: Synchronous Registered (Buffered)
    Speed: 667 MT/s
    Manufacturer: Hynix/Hyundai
    Serial Number: 393C405F
    Asset Tag: Not Specified
    Part Number: HMT31GR7BFR4C-H9 
    Rank: 2
    Configured Memory Speed: 667 MT/s
    Minimum Voltage: 1.5 V
    Maximum Voltage: 1.5 V
    Configured Voltage: 1.5 V

I have currently an old microcode from 2016 (PreSpectre) included in
coreboot ROM

and update it via Kernel to 0x6000852.

I did not test the vendor firmware at all with this board.

Also my system does not start with the shipped debian kernel
(4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64)
with used CONFIG_SLUB=y)

protection fault... i wrote an other email about this.

Instead i selfbuild a vanila kernel 4.19.62 with CONFIG_SLAB=y

So my wild guess is that coreboot does not initlize the new OPCODES
coming with the new microcode in a correct way.

best regards

the nekoboi

Am 31.07.19 um 18:17 schrieb Paul Menzel:
> Dear Kinky,
>
> On 7/30/19 11:18 AM, Kinky Nekoboi wrote:
> > loading the microcode via Linux Kernel works.
> >
> > including it via coreboot causes General Protection Faults.
> >
> > See included bootlog.
>
> We hit the same issue on our board, and reported it to the Linux kernel
> developers [1].
>
> Unfortunately, we didn’t have more resources to pursue this further.
>
> What is your configuration? How many processors, how much RAM?
>
> So, loading it from GNU/Linux (initramfs) as Tom asked, seems to
> work. I guess it’s the same with the vendor firmware?
>
> As Tom tested it on a similar custom AMD board (with supposedly
> microcode updates updated in the *vendor firmware*, and it worked
> for him, there might be something wrong with how microcode updates
> are applied in coreboot.
>
> The user *sfs* in #[e-mail] did not have the
> problems if I remember correctly.
>
> Anyway, somebody with time and motivation would need to debug this. But
> it’d be great if you could check a few things and maybe chime in the
> LKML discussion.
>
> Kind regards,
>
> Paul
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rudolf Marek]

Dne 30. 07. 19 v 11:18 Kinky Nekoboi napsal(a):
> loading the microcode via Linux Kernel works.
>
> including it via coreboot causes General Protection Faults.

It fails on MSR write:

17.170377] RSP: 0018:ffffffff9d003e10 EFLAGS: 00010046
[   17.175699] RAX: 0000000000000001 RBX: ffff8b289d93a040 RCX: 0000000000000049

The RCX is set to 0x49 which is the new IBPB barrier MSR.

[   17.151362] Code: 7d 08 49 83 c5 18 4c 89 fa 31 f6 e8 1e 68 99 00 49 8b 45 00 48 85 c0 75 e5 e9 73 ff ff ff b9 49 00 00 00 b8 01 00 00 00 31 d2 <0f> 30 e9 86 fc ff ff e9 81 00 00 00 48 c7 c2 e0 18 02 00 31 c0 65

And failing opcode is WRMSR (0f 30)

Failing CPU is CPU 0, which is not what I was hoping for.
My hypothesis was that maybe some of the processors are not receiving the microcode update properly.
I would expect that CPU0 would have it correctly.

For some reason CPU is advertising that it can do IBPB via CPUID but still failing to do that in reality. Very strange.

Thanks,
Rudolf