| View previous topic :: View next topic |
| Author |
Message |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
 Posted: Sun Jan 14, 2018 7:08 pm Post subject: |
 |
|
while true,
The microcode for meltdown/spectre for your CPU may not be out yet.
Look at | Code: | | ls /lib/firmware/amd-ucode/ |
to see what is available.
Look at | Code: | | $ grep 'cpu fam' /proc/cpuinfo |
to see what you need.
With a cpu family : 16 CPU you would need to add | Code: | | amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin |
to your
(radeon/<YOUR-MODEL>.bin)
Its all the .bin files up to and including your cpu family. Do not remove the existing files or your video will not work any more.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
 |
while true
Guru
Joined: 07 Apr 2010
Posts: 532
Location: Ljubljana, Slovenia
|
| Posted: Sun Jan 14, 2018 7:25 pm Post subject: |
|
|
oi oi, so:
| Code: | $ ls /lib/firmware/amd-ucode/
microcode_amd.bin microcode_amd.bin.asc microcode_amd_fam15h.bin microcode_amd_fam15h.bin.asc microcode_amd_fam16h.bin microcode_amd_fam16h.bin.asc microcode_amd_fam17h.bin
$ grep 'cpu fam' /proc/cpuinfo
cpu family : 21
cpu family : 21
cpu family : 21
cpu family : 21
cpu family : 21
cpu family : 21
cpu family : 21
cpu family : 21 |
so my family is 21, and updates are up to 17? I still have to wait for my family? I will keep an eye on that.
_________________
Kind regards, Goran Mitic
alive
while true
kick ass |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 15, 2018 5:20 am Post subject: |
|
|
| krinn wrote: | | you should just disable KPTI, it's not use because of your cpu, |
| NeddySeagoon wrote: | | PTI is in your kernel but its not needed on your CPU, so its not used. |
Is disabling it completely correct? See Hu's response to an inquiry of mine earlier in that thread.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 15, 2018 5:35 am Post subject: |
|
|
| NeddySeagoon wrote: | With a cpu family : 16 CPU you would need to add | Code: | | amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin |
to your
(radeon/<YOUR-MODEL>.bin)
Its all the .bin files up to and including your cpu family. Do not remove the existing files or your video will not work any more. |
If you don't mind, would you help educate me on this? I didn't even realize microcode updates existed until these vulnerabilities.
In reading the microcode table from the Gentoo AMD microcode wiki, I see CPU family decimal values (from 'grep -m1 family /proc/cpuinfo') as 16, 17, 18 and 20 using microcode_amd.bin. With cpu family decimal 21 using microcode_amd_fam15h.bin and cpu family decimal 22 using microcode_amd_fam16h.bin.
That appears to tell me that "fam15h.bin" and "fam16h.bin" would not be appropriate for a decimal value cpu family of 16.
| Code: | grep -m1 family /proc/cpuinfo
cpu family : 16 |
Maybe they could have made it easier by mixing in octal as well 
Thanks.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 10:27 am Post subject: |
|
|
pjp,
It looks like you are educating me. :)
For many years, I've had the AMD microcode update option in my kernel but no microcode file. :(
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jan 15, 2018 10:56 am Post subject: |
|
|
| NeddySeagoon wrote: | pjp,
It looks like you are educating me. 
For many years, I've had the AMD microcode update option in my kernel but no microcode file. 
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though. |
Or BIOS
The BIOS applies a uCode to the CPU while it POST's (or whatever the UEFI calls it these days). This is the usual way uCode is updated for PC's and considering BIOS updates are traditionally windows-only applications this was the way.
Being able to on-the-fly update the uCode was added to make life easier for linux users and is the preferred way to update the uCode *IF* said files are available.
Even if you have never updated your BIOS, you will still have a uCode provided by it
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 15, 2018 2:02 pm Post subject: |
|
|
| pjp wrote: | | krinn wrote: | | you should just disable KPTI, it's not use because of your cpu, |
| NeddySeagoon wrote: | | PTI is in your kernel but its not needed on your CPU, so its not used. |
Is disabling it completely correct? See Hu's response to an inquiry of mine earlier in that thread. |
thanks for pointing this, however i disagree with Hu:
while the technique he describe could be use to actually know if the memory match a kernel area ; the real issue is that your cpu cache is fillled with that memory area.
To me they do (ok make it really clear, it's my own understanding of the issue, not actually real explains), but just how i think the meldown issue is:
- Execution instruction toward a memory area
- Cpu speculate on next instruction, and fill its cache with "what will be result of the next instruction" ; so you instruct cpu to access memory location, and cpu speculate that your next instruction will be fetch the content of that location.
-> if the next instruction is then the one the cpu has bet you will use, the cpu then check if you have rights to do so, and if not, cache clear.
-> if you pass the rights check, the result is already there because run previously -> speed increase, you are asking something and the cpu has already compute it and you get the result from its cache.
-> if the next instruction is not the one the cpu has bet you will use, drop cache result
I think that the idea of meltdown is:
force cpu to speculative execute an instruction, the execution fill cpu cache with result ; and instead of execute another instruction that would let cpu speculated on something else (as it would fill cache with result of this one), instead of doing the instruction the cpu has bet you would do next (that would trigger rights check), you directly fetch the cpu cache to read the result of the speculative run.
But you are only aware you have succeed at reading the cache result, you don't know the value of that result.
To make sure, the given address was a valid one, and that indeed the cpu has execute a real instruction speculatively for you, you should do that twice to check if the first and second execution speed match.
And i think Hu is showing that amd cpu are still affect by the "check twice" to see if you have use a real memory area or not.
| Tom Lendacky wrote: | | The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. |
And to me the amd guy is saying: amd cpu do checks prior execute the speculative instruction, and if that result would be pagefault (because you don't have rights to access it), the cpu doesn't execute it.
By doing so on amd cpu : you are still able to tell if the cpu has access a valid kernel memory area (by comparing timing result, you know the address was valid or not), but that's all, you cannot read the result from its cache, because the amd cpu has check if reading that area would end in fault prior execute the instruction, and its cache content is not the result of the instruction, but garbage.
From my understanding (and i'm certainly wrong there!), but backup by the amd guy claims, if i were an amd cpu owner, i would just remove KPTI, even knowing someone can check if a memory location is valid or not.
I'm not quiet sure if i would in real, i tend to be conservative and with my European culture, and as this has prove more than once to be the right thing to do, i may enable KPTI even my cpu would be an amd. You know: better safe than sorry. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Jan 16, 2018 4:57 am Post subject: |
|
|
| NeddySeagoon wrote: | pjp,
It looks like you are educating me.
For many years, I've had the AMD microcode update option in my kernel but no microcode file.
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though. |
Well, passing along information anyway. I thought I had just figured it out, then I saw your post
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Jan 16, 2018 5:04 am Post subject: |
|
|
| krinn wrote: | | thanks for pointing this, however i disagree with Hu: |
That's fine, I'm just focused on the issue referenced in the wikipedia entry. Just because it is written there doesn't mean it is accurate, but I'm not seeing much that is currently addressing that possible issue.
| krinn wrote: | | i tend to be conservative and with my European culture, and as this has prove more than once to be the right thing to do, i may enable KPTI even my cpu would be an amd. You know: better safe than sorry. |
I tend to be of the type that wants vulnerabilities corrected. At least until I see something more definitive, I'm leaving KPTI enabled in the kernel and turned on via the kernel cmdline. Thanks for the comments.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Azurael
n00b
Joined: 06 Oct 2013
Posts: 4
|
| Posted: Mon Jan 29, 2018 8:36 pm Post subject: |
|
|
None of the huge quantity of documentation on these issues makes it clear what exactly is supposed to mitigate Spectre Variant 1 (including Gentoo's own https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre - other than to say "This problem is mitigated by adding speculative fencing on affected code paths throughout the Linux kernel.") I've enabled KPTI and Retpoline and I'm building with GCC 7.3.0, what have I missed?!
| Code: | azurael@kitsune ~ $ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33+
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-gentoo #1 SMP Mon Jan 29 19:56:44 GMT 2018 x86_64
CPU is Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all, see --disclaimer |
Last edited by Azurael on Mon Jan 29, 2018 10:37 pm; edited 1 time in total |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Mon Jan 29, 2018 8:49 pm Post subject: |
|
|
Azurael,
Ask the kernel itself.
| Code: | # cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Vulnerable
Vulnerable: Minimal AMD ASM retpoline |
With 4.15.0 out now, I'll be updating. That's 4.15.0-rc8 built with gcc-7.2.0 on an AMD Phenom(tm) II X6 1090T
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Azurael
n00b
Joined: 06 Oct 2013
Posts: 4
|
| Posted: Mon Jan 29, 2018 9:11 pm Post subject: |
|
|
| NeddySeagoon wrote: | Azurael,
Ask the kernel itself.
| Code: | # cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Vulnerable
Vulnerable: Minimal AMD ASM retpoline |
With 4.15.0 out now, I'll be updating. That's 4.15.0-rc8 built with gcc-7.2.0 on an AMD Phenom(tm) II X6 1090T |
That's why I asked. It just says vulnerable. |
|
| Back to top |
|
|
manwe_
l33t
Joined: 01 Feb 2006
Posts: 632
Location: Kraków/Cracow, Poland
|
| Posted: Mon Jan 29, 2018 10:30 pm Post subject: |
|
|
Lack of information how to deal with all three vulnerabilities is really annoying.
| Code: | # grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline
|
Kernel 4.15.0 (gentoo-sources) with CONFIG_PAGE_TABLE_ISOLATION and CONFIG_RETPOLINE, compiled with gcc 7.3.0. Newest intel-microcode (20180108-r1) and linux firmware (20180119). Microcode update goes fine:
| Code: | # dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20
[ 0.997562] microcode: sig=0x306c3, pf=0x2, revision=0x23
[ 0.997651] microcode: Microcode Update Driver: v2.2.
|
And still I get "Vulnerable" for "spectre_v1". Did I miss something? |
|
| Back to top |
|
|
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
|
| Back to top |
|
|
manwe_
l33t
Joined: 01 Feb 2006
Posts: 632
Location: Kraków/Cracow, Poland
|
| Posted: Mon Jan 29, 2018 11:04 pm Post subject: |
|
|
Kernel adds "-mindirect-branch=thunk-extern" to make when CONFIG_RETPOLINE is turned on:
| Code: | root 24264 0.0 0.2 178620 35936 pts/4 R+ 00:04 0:00 /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1 -quiet -nostdinc -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D CONFIG_X86_X32_ABI -D CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_SSSE3=1 -D CONFIG_AS_CRC32=1 -D CONFIG_AS_AVX=1 -D CONFIG_AS_AVX2=1 -D CONFIG_AS_AVX512=1 -D CONFIG_AS_SHA1_NI=1 -D CONFIG_AS_SHA256_NI=1 -D RETPOLINE -D CC_HAVE_ASM_GOTO -D KBUILD_BASENAME="intel_cacheinfo" -D KBUILD_MODNAME="intel_cacheinfo" -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include -include ./include/linux/kconfig.h -MD arch/x86/kernel/cpu/.intel_cacheinfo.o.d arch/x86/kernel/cpu/intel_cacheinfo.c -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -quiet -dumpbase intel_cacheinfo.c -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern -mindirect-branch-register -auxbase-strip arch/x86/kernel/cpu/intel_cacheinfo.o -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Wno-format-security -Wno-sign-compare -Wno-frame-address -Wformat-truncation=0 -Wformat-overflow=0 -Wno-int-in-bool-context -Wframe-larger-than=2048 -Wno-unused-but-set-variable -Wunused-const-variable=0 -Wdeclaration-after-statement -Wno-pointer-sign -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -falign-jumps=1 -falign-loops=1 -funit-at-a-time -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -fstack-protector -fomit-frame-pointer -fno-var-tracking-assignments -fno-strict-overflow -fstack-check=no -fconserve-stack --param allow-store-data-races=0 -o -
|
|
|
| Back to top |
|
|
platojones
Veteran
Joined: 23 Oct 2002
Posts: 1602
Location: Just over the horizon
|
| Posted: Mon Jan 29, 2018 11:14 pm Post subject: |
|
|
| manwe_ wrote: | Lack of information how to deal with all three vulnerabilities is really annoying.
| Code: | # grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline
|
Kernel 4.15.0 (gentoo-sources) with CONFIG_PAGE_TABLE_ISOLATION and CONFIG_RETPOLINE, compiled with gcc 7.3.0. Newest intel-microcode (20180108-r1) and linux firmware (20180119). Microcode update goes fine:
| Code: | # dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20
[ 0.997562] microcode: sig=0x306c3, pf=0x2, revision=0x23
[ 0.997651] microcode: Microcode Update Driver: v2.2.
|
And still I get "Vulnerable" for "spectre_v1". Did I miss something? |
Sounds like something is coming to mitigate that in 4.16.x:
https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Variant-One-Linux-4.16 |
|
| Back to top |
|
|
manwe_
l33t
Joined: 01 Feb 2006
Posts: 632
Location: Kraków/Cracow, Poland
|
| Posted: Mon Jan 29, 2018 11:20 pm Post subject: |
|
|
| OK, so for now there's no fix for spectre_v1 (apart from bunch of LFENCES)? I hope this patchset will be backported to 4.15 soon. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Mon Jan 29, 2018 11:21 pm Post subject: |
|
|
manwe_,
Try 4.16.0-rc1 in a few weeks.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sat Feb 03, 2018 6:00 pm Post subject: |
|
|
For those interested on performance cost from using mindirect-branch=thunk, here's a benchmark that was done comparing thunk and thunk-inline (it was using gcc-8, so take it with a grain of salt on possible effects).
https://www.phoronix.com/scan.php?page=article&item=gcc8-mindirect-thunk&num=1
Beyond that, reading the gentoo dev mailing list, right now they are not indicating if people should set -mindirect-branch=thunk-extern (or which of the 3 thunks for that matter). The most that is said, is that the kernel will automatically be compiled with thunk-extern if its available.
Start of the message thread:https://archives.gentoo.org/gentoo-user/message/e17aac982002d2bcb75ec9c26b7b21f0
As far as thunk-extern goes, I haven't been seeing much of any information about it, beyond gcc-7.3/8 has it and the kernel will use it. According to the benchmark, it looks like thunk-inline gives a hefty performance hit from using that, where just thunk was minor for performance hit. It would be interesting to see more information between thunk, thunk-inline, and thunk-extern on which gives more protection and maybe also the performance cost for using it. |
|
| Back to top |
|
|
|
Networking & Security
