[gentoo-user] AMD microcode updates - where are they?!

[gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

I'm looking at dmesg output which on my Intel CPUS of various vintages shows 
"microcode updated early ..." but two different AMD APUs of mine do not show 
the same, despite AMD apparently releasing microcode updates going back to 
2011:

https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-microcode-updates-for-cpus-going-back-to-2011/

I have observed OEMs for laptop MoBos rarely if ever bother to release a UEFI/
BIOS firmware update past 1-2 years from launch of their products, while 
desktop OEMs may keep releasing updates for 3-5 years.

Since there are no OEM MoBo firmware releases and I see no "microcode updated 
early ..." message in dmesg, I thought of checking with other Gentoo users if 
I'm doing something wrong, or if this is a common observation for AMD CPU/
APUs?

PS. I include the microcode in the kernel, for both my Intel and AMD systems,  
rather than use an initramfs; e.g.

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam15h.bin ..."

PPS. This is all shown on one of the AMD APUs, way down during the booting 
process:

$ dmesg | grep -i micro
[    0.622441] [drm] Loading ARUBA Microcode
[    5.763242] [drm] Loading hainan Microcode
[    6.653025] microcode: CPU0: patch_level=0x06001119
[    6.657962] microcode: CPU1: patch_level=0x06001119
[    6.658890] microcode: CPU2: patch_level=0x06001119
[    6.659881] microcode: CPU3: patch_level=0x06001119
[    6.661136] microcode: Microcode Update Driver: v2.2.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: AMD microcode updates - where are they?!

[Ian Zimmerman]

On 2019-07-12 13:18, Mick wrote:

> $ dmesg | grep -i micro
> [    0.622441] [drm] Loading ARUBA Microcode
> [    5.763242] [drm] Loading hainan Microcode
> [    6.653025] microcode: CPU0: patch_level=0x06001119
> [    6.657962] microcode: CPU1: patch_level=0x06001119
> [    6.658890] microcode: CPU2: patch_level=0x06001119
> [    6.659881] microcode: CPU3: patch_level=0x06001119
> [    6.661136] microcode: Microcode Update Driver: v2.2.

I have a similar experience:

[    0.659996] microcode: CPU0: patch_level=0x010000c8
[    0.660001] microcode: CPU1: patch_level=0x010000c8
[    0.660006] microcode: CPU2: patch_level=0x010000c8
[    0.660011] microcode: CPU3: patch_level=0x010000c8
[    0.660029] microcode: Microcode Update Driver: v2.2.
[    7.853509] [drm] Loading RS780 Microcode

I have a 10h generation processor, and I also build in microcode_amd.bin
with the kernel.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

> > $ dmesg | grep -i micro
> > [    0.622441] [drm] Loading ARUBA Microcode
> > [    5.763242] [drm] Loading hainan Microcode
> > [    6.653025] microcode: CPU0: patch_level=0x06001119
> > [    6.657962] microcode: CPU1: patch_level=0x06001119
> > [    6.658890] microcode: CPU2: patch_level=0x06001119
> > [    6.659881] microcode: CPU3: patch_level=0x06001119
> > [    6.661136] microcode: Microcode Update Driver: v2.2.
>
> I have a similar experience:
>
> [    0.659996] microcode: CPU0: patch_level=0x010000c8
> [    0.660001] microcode: CPU1: patch_level=0x010000c8
> [    0.660006] microcode: CPU2: patch_level=0x010000c8
> [    0.660011] microcode: CPU3: patch_level=0x010000c8
> [    0.660029] microcode: Microcode Update Driver: v2.2.
> [    7.853509] [drm] Loading RS780 Microcode
>
> I have a 10h generation processor, and I also build in microcode_amd.bin
> with the kernel.
>

 Piledriver gets the early message barcelona/fam10h doesnt;

 # dmesg | grep microc
[    1.663099] microcode: microcode updated early to new
patch_level=0x06000852
[    1.664161] microcode: CPU0: patch_level=0x06000852
[    1.665147] microcode: CPU1: patch_level=0x06000852
[    1.666135] microcode: CPU2: patch_level=0x06000852
[    1.667119] microcode: CPU3: patch_level=0x06000852
[    1.668034] microcode: CPU4: patch_level=0x06000852
[    1.668955] microcode: CPU5: patch_level=0x06000852
[    1.670060] microcode: CPU6: patch_level=0x06000852
[    1.670985] microcode: CPU7: patch_level=0x06000852
[    1.672012] microcode: Microcode Update Driver: v2.2.

# dmesg | grep microc
[    1.700378] microcode: CPU0: patch_level=0x010000c8
[    1.700435] microcode: CPU1: patch_level=0x010000c8
[    1.700488] microcode: CPU2: patch_level=0x010000c8
[    1.700543] microcode: CPU3: patch_level=0x010000c8
[    1.700684] microcode: Microcode Update Driver: v2.2.

microcode_amd.bin hasn't changed since at least January 2018, so maybe
there hasnt been any updates for the recent CPU vulnerabilities.

Assuming the numbering is sequential its odd that the APU is at 0x06001119
but the latest from linux-firmware is only 0x010000c8. Are you sure the APU
is not fam16h ?

[-- Attachment #2: Type: text/html, Size: 2817 bytes --]

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

grep fam /proc/cpuinfo

-> 21 = 15h
-> 22 = 16h

[-- Attachment #2: Type: text/html, Size: 130 bytes --]

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 5325 bytes --]

Thank you both, for your replies.

On Saturday, 13 July 2019 01:56:30 BST Adam Carter wrote:
> > > $ dmesg | grep -i micro
> > > [    0.622441] [drm] Loading ARUBA Microcode
> > > [    5.763242] [drm] Loading hainan Microcode
> > > [    6.653025] microcode: CPU0: patch_level=0x06001119
> > > [    6.657962] microcode: CPU1: patch_level=0x06001119
> > > [    6.658890] microcode: CPU2: patch_level=0x06001119
> > > [    6.659881] microcode: CPU3: patch_level=0x06001119
> > > [    6.661136] microcode: Microcode Update Driver: v2.2.
> > 
> > I have a similar experience:
> > 
> > [    0.659996] microcode: CPU0: patch_level=0x010000c8
> > [    0.660001] microcode: CPU1: patch_level=0x010000c8
> > [    0.660006] microcode: CPU2: patch_level=0x010000c8
> > [    0.660011] microcode: CPU3: patch_level=0x010000c8
> > [    0.660029] microcode: Microcode Update Driver: v2.2.
> > [    7.853509] [drm] Loading RS780 Microcode
> > 
> > I have a 10h generation processor, and I also build in microcode_amd.bin
> > with the kernel.

I had not until now built in 'amd-ucode/microcode_amd.bin', only 'amd-ucode/
microcode_amd_fam15h.bin', because this laptop has a 15h family CPU:

# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       48 bits physical, 48 bits virtual
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           AuthenticAMD
CPU family:          21
Model:               19
Model name:          AMD A10-5750M APU with Radeon(tm) HD Graphics
Stepping:            1
CPU MHz:             1330.218
CPU max MHz:         2500.0000
CPU min MHz:         1400.0000
BogoMIPS:            4990.70
Virtualization:      AMD-V
L1d cache:           16K
L1i cache:           64K
L2 cache:            2048K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c 
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch 
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core 
perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save 
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

$ dmesg | grep family:
[    0.291910] smpboot: CPU0: AMD A10-5750M APU with Radeon(tm) HD Graphics 
(family: 0x15, model: 0x13, stepping: 0x1)


>  Piledriver gets the early message barcelona/fam10h doesnt;
> 
>  # dmesg | grep microc
> [    1.663099] microcode: microcode updated early to new
> patch_level=0x06000852
> [    1.664161] microcode: CPU0: patch_level=0x06000852
> [    1.665147] microcode: CPU1: patch_level=0x06000852
> [    1.666135] microcode: CPU2: patch_level=0x06000852
> [    1.667119] microcode: CPU3: patch_level=0x06000852
> [    1.668034] microcode: CPU4: patch_level=0x06000852
> [    1.668955] microcode: CPU5: patch_level=0x06000852
> [    1.670060] microcode: CPU6: patch_level=0x06000852
> [    1.670985] microcode: CPU7: patch_level=0x06000852
> [    1.672012] microcode: Microcode Update Driver: v2.2.

OK, mine is also a Piledriver (mobile) CPU according to these tables:

https://en.wikichip.org/wiki/amd/a10

However, I don't see any early microcode being loaded.  :-/

I added 'amd-ucode/microcode_amd.bin' in the kernel, just in case it was 
needed and rebooted, but still no difference.

> # dmesg | grep microc
> [    1.700378] microcode: CPU0: patch_level=0x010000c8
> [    1.700435] microcode: CPU1: patch_level=0x010000c8
> [    1.700488] microcode: CPU2: patch_level=0x010000c8
> [    1.700543] microcode: CPU3: patch_level=0x010000c8
> [    1.700684] microcode: Microcode Update Driver: v2.2.
> 
> microcode_amd.bin hasn't changed since at least January 2018, so maybe
> there hasnt been any updates for the recent CPU vulnerabilities.
> 
> Assuming the numbering is sequential its odd that the APU is at 0x06001119
> but the latest from linux-firmware is only 0x010000c8. Are you sure the APU
> is not fam16h ?

Yes, positive.  As I've shown above the laptop has an A10 fam15h mobile 
Piledriver processor.

The desktop has an A10 Steamroller, Kaveri APU:

$ dmesg | grep family:
[    0.269754] smpboot: CPU0: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G 
(family: 0x15, model: 0x30, stepping: 0x1)

It has the 'amd-ucode/microcode_amd_fam15h.bin' built in the kernel and it 
also shows no early microcode being loaded:

$ dmesg | grep micro
[    1.578553] microcode: CPU0: patch_level=0x06003106
[    1.579338] microcode: CPU1: patch_level=0x06003106
[    1.580943] microcode: CPU2: patch_level=0x06003106
[    1.581729] microcode: CPU3: patch_level=0x06003106
[    1.582608] microcode: Microcode Update Driver: v2.2.

Notice the patch number is slightly higher than the laptop's, which can be 
explained by the fact the desktop's Steamroller was launched in Jan 2014, 
while the laptop's Piledriver was launched in March 2013.

Anyway, this does not explain why your Piledriver at least is loading early 
the microcode, but mine isn't.  :-/

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On Saturday, 13 July 2019 02:13:00 BST Adam Carter wrote:
> grep fam /proc/cpuinfo
> 
> -> 21 = 15h
> -> 22 = 16h

Yep, here's the laptop:

$ grep fam -m1 /proc/cpuinfo 
cpu family	: 21

and here's the dekstop:

$ grep fam -m1 /proc/cpuinfo
cpu family	: 21

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Jack]

On 2019.07.12 08:18, Mick wrote:
> I'm looking at dmesg output which on my Intel CPUS of various  
> vintages shows
> "microcode updated early ..." but two different AMD APUs of mine do  
> not show
> the same, despite AMD apparently releasing microcode updates going  
> back to
> 2011:
> 
> https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-microcode-updates-for-cpus-going-back-to-2011/

I have not yet done any further searching or digging, but that link  
seems to only talk specifically about Windows updates, not generic  
firmware updates.

I have three different AMD based PCs, and so far, I don't see anything  
different from Mick.  However, on two Artix linux systems, I'm still  
not quite sure whether the microcode is in the initramfs or not.  I  
hate to admit I'm also not sure on my Gentoo box, having so far made  
only minor changes to the kernel from the June stage 3 tarball, and  
used genkernel to compile both kernel and initramfs.  I'm working on  
configuring 5.2.0, but it will take me a while to get through the  
complete configuration (starting from scratch.)

One suggestion - don't just grep for microcode, also check for  
"firmware" for which I use 'dmesg | egrep -i "firmware|microcode"'.

And, one question - if I have linux-firmware emerged with savedconfig  
use flag set, what's the best/easiest way to hunt through the actually  
available firmware, to check if I might have missed something  
relevant.  So far, I've just searched the git repository for the  
package.  I suppose I could have kept a copy of the manifest from the  
initial emerge (without savedconfig)  but I didn't think of it at the  
time.

Jack

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Saturday, 13 July 2019 17:21:40 BST Jack wrote:
> On 2019.07.12 08:18, Mick wrote:

> > https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-mic
> > rocode-updates-for-cpus-going-back-to-2011/
> I have not yet done any further searching or digging, but that link
> seems to only talk specifically about Windows updates, not generic
> firmware updates.

Yes, but any microcode releases are/should be CPU specific.  If they're 
released for applying via one OS, they should be available to others too.

Of course, if microcode has only been released to MoBo OEM's, then we're in 
the mercy of OEM commercial interests.  I'm sure when asked for an update they 
will try to sell to us all the latest models they have recently launched.  :p


> I have three different AMD based PCs, and so far, I don't see anything
> different from Mick.  However, on two Artix linux systems, I'm still
> not quite sure whether the microcode is in the initramfs or not.  I
> hate to admit I'm also not sure on my Gentoo box, having so far made
> only minor changes to the kernel from the June stage 3 tarball, and
> used genkernel to compile both kernel and initramfs.  I'm working on
> configuring 5.2.0, but it will take me a while to get through the
> complete configuration (starting from scratch.)

I'm not familiar with dracut to know what it uses as a default archiving 
engine and if you can run it to inspect directly the contents of an already 
created initramfs.  I know it can output on the console what it is including 
in initramfs at the time of creation.

Anyway, if you want to look at the initramfs contents manually, I suppose you 
will need to decompress your initramfs in a temporary directory to see its 
contents.  First find what archive format has been used.  

file /boot/EFI/... initramfs-XXX.img

will output gzip, bzip2, lzma or similar archive type.  Then create a 
temporary directory to work in and use the corresponding compression type:

mkdir ~/tmp_initramfs
cd ~/tmp_initramfs

zcat /boot/EFI/... initramfs-XXX.img | cpio -idmv

or 

bzcat /boot/EFI/... initramfs-XXX.img | cpio -idmv

or 

xv -dc < /boot/EFI/... initramfs-XXX.img | cpio -idmv

Something like the above ought to do the job.

> One suggestion - don't just grep for microcode, also check for
> "firmware" for which I use 'dmesg | egrep -i "firmware|microcode"'.

Well, 'firmware' will capture other firmware files, like graphics card, WiFi, 
BT, etc. rather than the CPU microcode.


> And, one question - if I have linux-firmware emerged with savedconfig
> use flag set, what's the best/easiest way to hunt through the actually
> available firmware, to check if I might have missed something
> relevant.  So far, I've just searched the git repository for the
> package.  I suppose I could have kept a copy of the manifest from the
> initial emerge (without savedconfig)  but I didn't think of it at the
> time.
> 
> Jack

Look under your /lib/firmware/ directory for the file you want to use, or the 
file dmesg complains is missing.  For microcode there will be no complaining, 
but for other hardware there usually is something along the lines:  "failed to 
load blah-blah.bin, file not found."

The appropriate microcode file for your AMD CPUs can be deduced from the table 
here:

https://wiki.gentoo.org/wiki/AMD_microcode

and it should be stored under your:

/lib/firmware/amd-ucode/

after you install linux-firmware.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

On Saturday, 13 July 2019 18:18:35 BST Mick wrote:
> or
> 
> xv -dc < /boot/EFI/... initramfs-XXX.img | cpio -idmv

Oops!  Typo alert!  xv should of course be 'xz'.  I think you can also use 
lzcat.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Jack]

On 2019.07.13 13:18, Mick wrote:
> On Saturday, 13 July 2019 17:21:40 BST Jack wrote:
> > On 2019.07.12 08:18, Mick wrote:
[snip....]
>> And, one question - if I have linux-firmware emerged with  
>> savedconfig use flag set, what's the best/easiest way to hunt  
>> through the actually available firmware, to check if I might have  
>> missed something relevant.  So far, I've just searched the git  
>> repository for the package.  I suppose I could have kept a copy of  
>> the manifest from the initial emerge (without savedconfig)  but I  
>> didn't think of it at the time.
> 
> Look under your /lib/firmware/ directory for the file you want to  
> use, or the file dmesg complains is missing.  For microcode there  
> will be no complaining, but for other hardware there usually is  
> something along the lines:  "failed to load blah-blah.bin, file not  
> found."
If linux-firmware is emerged with the savedconfig use flag, then only  
the firmware not deleted from the config file is left.  I did find a  
few extras based on the "failed to load..." messages after my initial  
overzealous trimming of that config file.  My current concern is indeed  
with the microcode, about which no complaint.  Looking at the link  
below shows me I am missing the files for my 17h family Ryzen CPU.  It  
will be a bit before I can reboot to see if it does load them once I  
re-emerge linux-firmware to get them.

I'll update again once I've done that.

Jack

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Saturday, 13 July 2019 18:42:27 BST Jack wrote:
>
> If linux-firmware is emerged with the savedconfig use flag, then only
> the firmware not deleted from the config file is left.  

Yes.  I used to do this, but gave up after a while.

> I did find a
> few extras based on the "failed to load..." messages after my initial
> overzealous trimming of that config file.  My current concern is indeed
> with the microcode, about which no complaint.  Looking at the link
> below shows me I am missing the files for my 17h family Ryzen CPU.  It
> will be a bit before I can reboot to see if it does load them once I
> re-emerge linux-firmware to get them.

Make sure the corresponding AMDGPU driver settings are built in the kernel, 
not as modules.

Ryzen CPUs are new(ish) and the MoBo OEMs should still be releasing UEFI/BIOS 
firmware updates, which will contain any needed microcode patches.  You'll 
obtain these next time you flash your BIOS with the latest release, if/when 
there is one available.  Your 'dmesg | grep micro' patch number will change as 
a result, but there will be no 'early microcode update ...' message since the 
OS will not be applying any microcode patches itself.  

It is older CPUs which need the patches, since OEMs usually abandon any 
intention to support their hardware beyond the nominal warranty period.


> I'll update again once I've done that.
> 
> Jack

Cool, thanks for your input.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Corbin]

For reference, the .config file for the kernel should have something
along the lines of this:

> #
> # Firmware loader
> #
> CONFIG_FW_LOADER=y
> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin
> amd-ucode/microcode_amd_fam15h.bin amdgpu/polaris10_ce.bin
> amdgpu/polaris10_ce_2.bin amdgpu/polaris10_k_smc.bin
> amdgpu/polaris10_mc.bin amdgpu/polaris10_me.bin
> amdgpu/polaris10_me_2.bin amdgpu/polaris10_mec.bin
> amdgpu/polaris10_mec2.bin amdgpu/polaris10_mec2_2.bin
> amdgpu/polaris10_pfp.bin amdgpu/polaris10_pfp_2.bin
> amdgpu/polaris10_rlc.bin amdgpu/polaris10_sdma.bin
> amdgpu/polaris10_sdma1.bin amdgpu/polaris10_smc.bin
> amdgpu/polaris10_smc_sk.bin amdgpu/polaris10_uvd.bin
> amdgpu/polaris10_vce.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
> CONFIG_FW_LOADER_USER_HELPER=y

CPU is a AMD FX-9590 ( Fam15h )

Video is a RX480 ( Polaris 10 )

And, yes, both microcode updates ( Fam10h / Fam15h ) need to be builtin.

Previous generation CPU updates will be builtin, even if you try to
exclude them.


Corbin

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On Saturday, 13 July 2019 19:16:18 BST Corbin wrote:
> For reference, the .config file for the kernel should have something
> 
> along the lines of this:
> > #
> > # Firmware loader
> > #
> > CONFIG_FW_LOADER=y
> > CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin
> > amd-ucode/microcode_amd_fam15h.bin amdgpu/polaris10_ce.bin
> > amdgpu/polaris10_ce_2.bin amdgpu/polaris10_k_smc.bin
> > amdgpu/polaris10_mc.bin amdgpu/polaris10_me.bin
> > amdgpu/polaris10_me_2.bin amdgpu/polaris10_mec.bin
> > amdgpu/polaris10_mec2.bin amdgpu/polaris10_mec2_2.bin
> > amdgpu/polaris10_pfp.bin amdgpu/polaris10_pfp_2.bin
> > amdgpu/polaris10_rlc.bin amdgpu/polaris10_sdma.bin
> > amdgpu/polaris10_sdma1.bin amdgpu/polaris10_smc.bin
> > amdgpu/polaris10_smc_sk.bin amdgpu/polaris10_uvd.bin
> > amdgpu/polaris10_vce.bin"
> > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
> > CONFIG_FW_LOADER_USER_HELPER=y

As I understand it the CONFIG_FW_LOADER_USER_HELPER has some edge use cases, 
but is not needed for our hardware/firmware.


> CPU is a AMD FX-9590 ( Fam15h )
> 
> Video is a RX480 ( Polaris 10 )
> 
> And, yes, both microcode updates ( Fam10h / Fam15h ) need to be builtin.

Are you sure about this?

I added 'amd-ucode/microcode_amd.bin' for Fam10h, rebooted and nothing changed 
here as far as microcode patches is concerned.  I am not using savedconfig on 
this PC, so all amd-ucode binaries are available to be loaded from the 
filesystem.


> Previous generation CPU updates will be builtin, even if you try to
> exclude them.

Fine, so following the wiki page and ONLY adding the microcode specific to the 
CPU  family should still work.

> Corbin

Thanks Corbin, I wonder if despite articles about microcode patch releases to 
deal with spectre and what not, there are just no patches made available for 
my aging AMD CPUs.
-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Wols Lists]

On 13/07/19 20:23, Mick wrote:
> Thanks Corbin, I wonder if despite articles about microcode patch releases to 
> deal with spectre and what not, there are just no patches made available for 
> my aging AMD CPUs.

Or Spectre and what not are Intel specific ...

I know a lot of the reports said many of the exploits don't work on AMD.
It's something to do with the way Intel has implemented speculative
execution, and AMD doesn't use that technique.

Cheers,
Wol

Re: [gentoo-user] AMD microcode updates - where are they?!

[Rich Freeman]

On Sat, Jul 13, 2019 at 4:16 PM Wols Lists <antlists@youngman.org.uk> wrote:
>
> On 13/07/19 20:23, Mick wrote:
> > Thanks Corbin, I wonder if despite articles about microcode patch releases to
> > deal with spectre and what not, there are just no patches made available for
> > my aging AMD CPUs.
>
> Or Spectre and what not are Intel specific ...
>
> I know a lot of the reports said many of the exploits don't work on AMD.
> It's something to do with the way Intel has implemented speculative
> execution, and AMD doesn't use that technique.

Some spectre-related vulnerabilities apply to AMD, and some do not.
Most of the REALLY bad ones do not, but I believe that some of the AMD
ones still require microcode updates to be mitigated in the most
efficient way.

Take a look in /sys/devices/system/cpu/vulnerabilities on your system
for the kernel's assessment of what vulnerabilities apply, and how
they are being mitigated.  What you want to see is every single one
either saying "Not affected" or they start with "Mitigation:"  If you
see one starting with something like Partial Mitigation or Vulnerable
you should Google if there is something you can do to improve this.

Note that this assumes you have a current kernel.  The kernel can only
report the vulnerabilities it knows about, so if you're running some
kernel from 9 months ago it won't know about everything.

For reference, on my Ryzen 5 1600 I get:
for x in * ; do echo -n "$x: " ; cat $x ; done

l1tf: Not affected
mds: Not affected
meltdown: Not affected
spec_store_bypass: Mitigation: Speculative Store Bypass disabled via
prctl and seccomp
spectre_v1: Mitigation: __user pointer sanitization
spectre_v2: Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling

-- 
Rich

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

On Saturday, 13 July 2019 22:01:02 BST Rich Freeman wrote:
> On Sat, Jul 13, 2019 at 4:16 PM Wols Lists <antlists@youngman.org.uk> wrote:
> > On 13/07/19 20:23, Mick wrote:
> > > Thanks Corbin, I wonder if despite articles about microcode patch
> > > releases to deal with spectre and what not, there are just no patches
> > > made available for my aging AMD CPUs.
> > 
> > Or Spectre and what not are Intel specific ...
> > 
> > I know a lot of the reports said many of the exploits don't work on AMD.
> > It's something to do with the way Intel has implemented speculative
> > execution, and AMD doesn't use that technique.
> 
> Some spectre-related vulnerabilities apply to AMD, and some do not.
> Most of the REALLY bad ones do not, but I believe that some of the AMD
> ones still require microcode updates to be mitigated in the most
> efficient way.

Yes, the A10 is vulnerable to:

 CVE-2017-5753 (Spectre Variant 1, bounds check bypass)
 CVE-2017-5715 (Spectre Variant 2, branch target injection)


> Take a look in /sys/devices/system/cpu/vulnerabilities on your system
> for the kernel's assessment of what vulnerabilities apply, and how
> they are being mitigated.  What you want to see is every single one
> either saying "Not affected" or they start with "Mitigation:"  If you
> see one starting with something like Partial Mitigation or Vulnerable
> you should Google if there is something you can do to improve this.
> 
> Note that this assumes you have a current kernel.  The kernel can only
> report the vulnerabilities it knows about, so if you're running some
> kernel from 9 months ago it won't know about everything.
> 
> For reference, on my Ryzen 5 1600 I get:
> for x in * ; do echo -n "$x: " ; cat $x ; done
> 
> l1tf: Not affected
> mds: Not affected
> meltdown: Not affected
> spec_store_bypass: Mitigation: Speculative Store Bypass disabled via
> prctl and seccomp
> spectre_v1: Mitigation: __user pointer sanitization
> spectre_v2: Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling

I get the same output on both AMD systems running gentoo-sources-4.19.57.

I've also used this script for some more detailed checking and testing:

https://github.com/speed47/spectre-meltdown-checker

Unlike my old Intel which lights up like a christmas tree with "Vulnerable, no 
microcode found" because Intel has thrown its users to the kerb, both AMDs 
show "Not Vulnerable" and for some of the vulnerabilities it reports:

(your CPU vendor reported your CPU model as not vulnerable)

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

On Saturday, 13 July 2019 23:03:11 BST Mick wrote:

> Unlike my old Intel which lights up like a christmas tree with "Vulnerable,
> no microcode found" because Intel has thrown its users to the kerb, both
> AMDs show "Not Vulnerable" and for some of the vulnerabilities it reports:
> 
> (your CPU vendor reported your CPU model as not vulnerable)

This last line made me think a bit more.  Scratching around I see there are 
separate patch files with AMD microcode updates offered for the various CPU 
families.  My simplistic assumption so far has been *all* CPUs of a certain 
family will apply the corresponding patch file microcode update, either via a 
new UEFI/BIOS firmware, or via the OS.

Clearly this is not so.  If I remove 'amd-ucode/microcode_amd_fam15h.bin' from 
my kernel firmware directive completely, or add amd-ucode/ patch files for 
every family, or even try to manually reload the microcode:

echo 1 > /sys/devices/system/cpu/microcode/reload

there is no change in dmesg.  Clearly my CPU does not load any microcode 
update, other than what might be already available in the old UEFI MoBo 
firmware and this is loaded before the OS starts booting.

Then I came across this old message regarding Piledriver CPUs:

https://lists.debian.org/debian-security/2016/03/msg00084.html

The post refers to model 2 of cpu family 21.  Not all models in the same 
family, only model 2.  So I am thinking although patch files are named per CPU 
family, whether they are applicable and applied as an update to the CPU is 
probably determined by the particular CPU *model*.  Logically, errata in 
previous CPU revisions may have been fixed in later models of the same family 
and therefore such microcode updates would not be needed.  When offered by the 
OS the CPU won't select to have them applied.

This explains why my AMD models, which are later revisions of the same 15h 
family do not apply any microcode updates - they don't need them.

Please share if you know differently and thank you all for your responses.
-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

> Then I came across this old message regarding Piledriver CPUs:
>
> https://lists.debian.org/debian-security/2016/03/msg00084.html
>
> The post refers to model 2 of cpu family 21.  Not all models in the same
> family, only model 2.  So I am thinking although patch files are named per
> CPU
> family, whether they are applicable and applied as an update to the CPU is
> probably determined by the particular CPU *model*.  Logically, errata in
> previous CPU revisions may have been fixed in later models of the same
> family
> and therefore such microcode updates would not be needed.  When offered by
> the
> OS the CPU won't select to have them applied.
>
> This explains why my AMD models, which are later revisions of the same 15h
> family do not apply any microcode updates - they don't need them.
>
> Please share if you know differently and thank you all for your responses.


Sounds reasonable, but the 15h code was updated mid 2018, so unless the cpu
or BIOS update is from after then, i would be concerned.

If your APUs return similar to this then then there's nothing to worry about

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user
pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD
retpoline, IBPB: conditional, STIBP: disabled, RSB filling

[-- Attachment #2: Type: text/html, Size: 2183 bytes --]

[gentoo-user] Re: AMD microcode updates - where are they?!

[Ian Zimmerman]

On 2019-07-13 19:06, Mick wrote:

> > If linux-firmware is emerged with the savedconfig use flag, then
> > only the firmware not deleted from the config file is left.
> 
> Yes.  I used to do this, but gave up after a while.

I find it odd that there is apparently no central way to track which
firmwares are being loaded without a debugging kernel.

The relevant messages in linux/drivers/base/firmware_loader/main.c are
all dev_dbg(), which as I understand does nothing on a non-debug kernel.
Even the message printed when the firmware file is missing is of that
type.

I guess I could turn on the userspace helper, set it to some script that
just logs every request and fails, and then remove the whole
/lib/firmware tree, but that is a _really_ round-about way.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] AMD microcode updates - where are they?!

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Sun, Jul 14, 2019 at 4:06 AM Mick <michaelkintzios@gmail.com> wrote:

> On Saturday, 13 July 2019 18:42:27 BST Jack wrote:
> >
> > If linux-firmware is emerged with the savedconfig use flag, then only
> > the firmware not deleted from the config file is left.
>
> Yes.  I used to do this, but gave up after a while.


Kernel 5.3 is getting the ability to load .xz compressed firmware, so
/lib/firmware goes from 460MB to under 80MB.

[-- Attachment #2: Type: text/html, Size: 793 bytes --]

[gentoo-user] Re: AMD microcode updates - where are they?!

[Ian Zimmerman]

UH-OH, Self-followup:

On 2019-07-14 21:30, Ian Zimmerman wrote:

> I find it odd that there is apparently no central way to track which
> firmwares are being loaded without a debugging kernel.
> 
> The relevant messages in linux/drivers/base/firmware_loader/main.c are
> all dev_dbg(), which as I understand does nothing on a non-debug kernel.
> Even the message printed when the firmware file is missing is of that
> type.
> 
> I guess I could turn on the userspace helper, set it to some script that
> just logs every request and fails, and then remove the whole
> /lib/firmware tree, but that is a _really_ round-about way.

Solved with a kernel patch:

--- a/drivers/base/firmware_loader/main.c	2019-07-13 23:01:15.000000000 -0700
+++ b/drivers/base/firmware_loader/main.c	2019-07-14 23:33:22.348028910 -0700
@@ -336,7 +336,7 @@
 					 path);
 			continue;
 		}
-		dev_dbg(device, "direct-loading %s\n", fw_priv->fw_name);
+		pr_notice("direct-loading firmware %s\n", fw_priv->fw_name);
 		fw_priv->size = size;
 		fw_state_done(fw_priv);
 		break;


-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] AMD microcode updates - where are they?!

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Sat, 13 Jul 2019 18:18:35 +0100, Mick wrote:

> Anyway, if you want to look at the initramfs contents manually, I
> suppose you will need to decompress your initramfs in a temporary
> directory to see its contents.  First find what archive format has been
> used.  
> 
> file /boot/EFI/... initramfs-XXX.img
> 
> will output gzip, bzip2, lzma or similar archive type.  Then create a 
> temporary directory to work in and use the corresponding compression
> type:
> 
> mkdir ~/tmp_initramfs
> cd ~/tmp_initramfs
> 
> zcat /boot/EFI/... initramfs-XXX.img | cpio -idmv

Did you build the initramfs with genkernel or dracut? If the latter, just
run lsinitrd, which lists the contents of the current kernel's initramfs.
You can also inspect individual files within the initramfs.


-- 
Neil Bothwick

Your lack of organisation does not represent an
emergency in my world.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Monday, 15 July 2019 22:18:12 BST Ian Zimmerman wrote:
> UH-OH, Self-followup:
> 
> On 2019-07-14 21:30, Ian Zimmerman wrote:
> > I find it odd that there is apparently no central way to track which
> > firmwares are being loaded without a debugging kernel.
> > 
> > The relevant messages in linux/drivers/base/firmware_loader/main.c are
> > all dev_dbg(), which as I understand does nothing on a non-debug kernel.
> > Even the message printed when the firmware file is missing is of that
> > type.
> > 
> > I guess I could turn on the userspace helper, set it to some script that
> > just logs every request and fails, and then remove the whole
> > /lib/firmware tree, but that is a _really_ round-about way.
> 
> Solved with a kernel patch:
> 
> --- a/drivers/base/firmware_loader/main.c	2019-07-13 23:01:15.000000000
> -0700 +++ b/drivers/base/firmware_loader/main.c	2019-07-14
> 23:33:22.348028910 -0700 @@ -336,7 +336,7 @@
>  					 path);
>  			continue;
>  		}
> -		dev_dbg(device, "direct-loading %s\n", fw_priv-
>fw_name);
> +		pr_notice("direct-loading firmware %s\n", fw_priv-
>fw_name);
>  		fw_priv->size = size;
>  		fw_state_done(fw_priv);
>  		break;


Thanks Ian, nothing different with the patch implemented.  I am becoming 
convinced there is no applicable microcode patch for my fam + model of AMD 
CPUs.

$ dmesg | egrep -i "firmware|microcode"
[    0.000000] [Firmware Info]: CPU: Re-enabling disabled Topology Extensions 
Support.
[    0.343586] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[    0.351361] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 
00-3f] only partially covers this bridge
[    0.627638] [drm] Loading ARUBA Microcode
[    0.629254] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[    5.753421] [drm] Loading hainan Microcode
[    6.643785] microcode: CPU0: patch_level=0x06001119
[    6.647663] microcode: CPU1: patch_level=0x06001119
[    6.649170] microcode: CPU2: patch_level=0x06001119
[    6.650136] microcode: CPU3: patch_level=0x06001119
[    6.651110] microcode: Microcode Update Driver: v2.2.
[    8.125143] psmouse serio1: elantech: assuming hardware version 3 (with 
firmware version 0x450f03)
[    9.938954] psmouse serio1: elantech: assuming hardware version 3 (with 
firmware version 0x450f03)
[   30.738249] firmware_class: direct-loading firmware regulatory.db
[   30.738915] firmware_class: direct-loading firmware regulatory.db.p7s

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Corbin]

On 7/14/19 8:26 AM, Mick wrote:
> Then I came across this old message regarding Piledriver CPUs:
> https://lists.debian.org/debian-security/2016/03/msg00084.html The
> post refers to model 2 of cpu family 21. Not all models in the same
> family, only model 2. So I am thinking although patch files are named
> per CPU family, whether they are applicable and applied as an update
> to the CPU is probably determined by the particular CPU *model*.
> Logically, errata in previous CPU revisions may have been fixed in
> later models of the same family and therefore such microcode updates
> would not be needed. When offered by the OS the CPU won't select to
> have them applied. This explains why my AMD models, which are later
> revisions of the same 15h family do not apply any microcode updates -
> they don't need them. Please share if you know differently and thank
> you all for your responses. 
Remember a while back when I mentioned that "lwp" had disappeared from
my /proc/cpuinfo?
They restored "lwp" with this commit :
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=7518922bd5b98b137af7aaf3c836f5a498e91609
So it stands to reason that the microcode only applies specific patches
to specific problems per CPU.


Reference :
> Darkstar ~ # cat /proc/cpuinfo
> processor    : 0
> vendor_id    : AuthenticAMD
> cpu family    : 21
> model        : 2
> model name    : AMD FX(tm)-9590 Eight-Core Processor
> stepping    : 0
> microcode    : 0x6000852
> cpu MHz        : 4685.390
> cache size    : 2048 KB
Output of /sys/devices/system/cpu/vulnerabilities :
>
> Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/l1tf
> Not affected
> Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/mds
> Not affected
> Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/meltdown
> Not affected
> Darkstar ~ # cat
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
> Mitigation: Speculative Store Bypass disabled
> Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
> Mitigation: __user pointer sanitization
> Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> Mitigation: Full AMD retpoline, IBPB: always-on, STIBP: disabled, RSB
> filling

Corbin

Re: [gentoo-user] AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

On Wednesday, 17 July 2019 04:21:07 BST Corbin wrote:
> On 7/14/19 8:26 AM, Mick wrote:
> > Then I came across this old message regarding Piledriver CPUs:
> > https://lists.debian.org/debian-security/2016/03/msg00084.html The
> > post refers to model 2 of cpu family 21. Not all models in the same
> > family, only model 2. So I am thinking although patch files are named
> > per CPU family, whether they are applicable and applied as an update
> > to the CPU is probably determined by the particular CPU *model*.
> > Logically, errata in previous CPU revisions may have been fixed in
> > later models of the same family and therefore such microcode updates
> > would not be needed. When offered by the OS the CPU won't select to
> > have them applied. This explains why my AMD models, which are later
> > revisions of the same 15h family do not apply any microcode updates -
> > they don't need them. Please share if you know differently and thank
> > you all for your responses.
> 
> Remember a while back when I mentioned that "lwp" had disappeared from
> my /proc/cpuinfo?
> 
> They restored "lwp" with this commit :
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi
> > t/commit/?id=7518922bd5b98b137af7aaf3c836f5a498e91609
> So it stands to reason that the microcode only applies specific patches
> to specific problems per CPU.
> 
> Reference :
> > Darkstar ~ # cat /proc/cpuinfo
> > processor    : 0
> > vendor_id    : AuthenticAMD
> > cpu family    : 21
> > model        : 2
> > model name    : AMD FX(tm)-9590 Eight-Core Processor
> > stepping    : 0
> > microcode    : 0x6000852
> > cpu MHz        : 4685.390
> > cache size    : 2048 KB
> 
> Output of /sys/devices/system/cpu/vulnerabilities :
> > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/l1tf
> > Not affected
> > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/mds
> > Not affected
> > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/meltdown
> > Not affected
> > Darkstar ~ # cat
> > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
> > Mitigation: Speculative Store Bypass disabled
> > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
> > Mitigation: __user pointer sanitization
> > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> > Mitigation: Full AMD retpoline, IBPB: always-on, STIBP: disabled, RSB
> > filling
> 
> Corbin

Hmm ... My last line looks the same like Rich's, but different to yours:

# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling

I don't have IBPB mentioned in there at all.  I'm on gentoo-sources-4.19.57.  
Are you running a later kernel?

According to this article a microcode update seems to be necessary, but I'm 
not sure if this statement only applies to Intel CPUs:

https://access.redhat.com/articles/3311301#indirect-branch-prediction-barriers-ibpb-10

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] AMD microcode updates - where are they?!

[Corbin]

On 7/17/19 5:58 AM, Mick wrote:
> Hmm ... My last line looks the same like Rich's, but different to yours:
>
> # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
>
> I don't have IBPB mentioned in there at all.  I'm on gentoo-sources-4.19.57.  
> Are you running a later kernel?
>
> According to this article a microcode update seems to be necessary, but I'm 
> not sure if this statement only applies to Intel CPUs:
>
> https://access.redhat.com/articles/3311301#indirect-branch-prediction-barriers-ibpb-10
>
------

My kernel version : 4.19.59

Please note that I am using the "experimental" USE FLAG for
"sys-kernel/gentoo-sources".

CPU selected is "AMD Piledriver"

Also, I am using the latest firmware for "sys-kernel/linux-firmware" (
20190712:0 ).

Kernel command line parameters on boot :

"spectre_v2=on spectre_v2_user=on spec_store_bypass_disable=on"


Corbin

[gentoo-user] Re: AMD microcode updates - where are they?!

[Ian Zimmerman]

On 2019-07-17 07:46, Corbin wrote:

> My kernel version : 4.19.59
> 
> Please note that I am using the "experimental" USE FLAG for
> "sys-kernel/gentoo-sources".
> 
> CPU selected is "AMD Piledriver"
> 
> Also, I am using the latest firmware for "sys-kernel/linux-firmware" (
> 20190712:0 ).
> 
> Kernel command line parameters on boot :
> 
> "spectre_v2=on spectre_v2_user=on spec_store_bypass_disable=on"

A couple paragraphs down in that redhat article it says:

    Red Hat Enterprise Linux defaults on AMD CPUs: Due to the
    differences in underlying hardware implementation, AMD X86 systems
    are not vulnerable to variant #3. The correct default values will be
    set on AMD hardware based on dynamic checks during the boot
    sequence.

    pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode update is applied
    pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates

    Note: A microcode patch provided by the vendor must be applied in order for the tunables to be visible.

which of course is self-contradictory, so not a full answer but maybe a
clue.

Are those settings meant to go on a boot command line?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] AMD microcode updates - where are they?!

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

>
> Hmm ... My last line looks the same like Rich's, but different to yours:
>
> # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
>
> I don't have IBPB mentioned in there at all.  I'm on
> gentoo-sources-4.19.57.
> Are you running a later kernel?
>
> According to this article a microcode update seems to be necessary, but
> I'm
> not sure if this statement only applies to Intel CPUs:
>
>
> https://access.redhat.com/articles/3311301#indirect-branch-prediction-barriers-ibpb-10
>
>
My piledriver output from an old 4.19 has IBPB, so given that redhat info,
it looks like you do have old microcode. I don't pass anything via the
kernel command line, as I assume the defaults are good.

$ cat kern-4.19.7-vuln.txt
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user
pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD
retpoline, IBPB: conditional, STIBP: disabled, RSB filling

FWIW
$ md5sum /lib/firmware/amd-ucode/microcode_amd_fam15h.bin
3bdedb4466186a79c469f62120f6d7bb
 /lib/firmware/amd-ucode/microcode_amd_fam15h.bin

[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Corbin]

On 7/17/19 3:51 PM, Ian Zimmerman wrote:
>     pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode update is applied
>     pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates
>
>     Note: A microcode patch provided by the vendor must be applied in order for the tunables to be visible.
>
> which of course is self-contradictory, so not a full answer but maybe a
> clue.
>
> Are those settings meant to go on a boot command line?
>
As for what Red Hat / Fedora is doing, no idea.

The parameters I used came from the kernel documentation.


Corbin

Re: [gentoo-user] Re: AMD microcode updates - where are they?!

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

On Thursday, 18 July 2019 13:33:36 BST Corbin wrote:
> On 7/17/19 3:51 PM, Ian Zimmerman wrote:
> >     pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode
> >     update is applied pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on
> >     older processors that can disable indirect branch prediction without
> >     microcode updates
> >     
> >     Note: A microcode patch provided by the vendor must be applied in
> >     order for the tunables to be visible.> 
> > which of course is self-contradictory, so not a full answer but maybe a
> > clue.

I did read this but wasn't sure what to deduce from it.  I took it to mean 
earlier CPUs won't receive a microcode patch, but will still have spectre 
mitigated, presumably using a different method.  Later CPUs will receive a 
patch.  My AMD APUs are later fam15h models and if the above is to be believed 
they probably ought to have received a patch - but none is observable.  :-/

Then I thought the note in the RHL article may need to be taken literally, to 
mean a microcode patch will just make tunables *visible*, rather than present.


> > Are those settings meant to go on a boot command line?
> 
> As for what Red Hat / Fedora is doing, no idea.
> 
> The parameters I used came from the kernel documentation.
> 
> 
> Corbin

According to kernel-4.19.57 docs at least, all CPU vulnerabilities and spectre 
related mitigations are automatically switched on, without the need to specify 
anything on the kernel line.  In addition, the selection of individual 
spectre_v2 mitigation methods is determined dynamically "... at run time 
according to the CPU, the available microcode, the setting of the 
CONFIG_RETPOLINE configuration option, and the compiler with which the kernel 
was built."

Anyway, selecting 'spectre_v2=on' "... will also enable the mitigation against 
user space to user space task attacks", so this is a useful option to use.

Regarding ibpb not being displayed under my /sys fs the docs say:

Default mitigation:
                    If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"

Therefore, I am not sure if ibpb is meant to show up unless it has been 
specified on the kernel line as a spectre_v2_user mitigation method.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]