| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Mon Jan 15, 2018 6:18 am Post subject: |
 |
|
Can somebody explain to me what the microcode updates are good for?
Versions for my cpu have been updated, but (unsurprisingly) https://github.com/Eugnis/spectre-attack still renders the machine as exploitable (though I didn't check whether it tests spectre #1 or #2). ("unsurprisingly", because it was announced somewhere that these 2 cannot be fixed by microcode).
And meltdown (i.e. #3) is fixed by pti in the kernel, isn't it? (At least, this is correct according to https://github.com/raphaelsc/Am-I-affected-by-Meltdown). I didn't try ttps://github.com/IAIK/meltdown yet, because as I understood it also does not more than the other meltdown checker but only uses it to demonstrate some exploits. And I read also somewhere that meltdown cannot be fixed by microcode, either.
Somewhere it was announced that the microcode updates are necessary to make the upcoming compiler patches work (AFAIK they add some new instruction), but somewhere else it was announced that these upcoming compiler patches will also work without that instruction. So I am really confused about the purpose of the microcode updates (and also how to check whether my updated version really contains the "mitigations" whatever they are, e.g. whether the new instruction has been added...)
Edit: Inserted URLs for clarity which tests I am referring to... |
|
| Back to top |
|
 |
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jan 15, 2018 7:11 am Post subject: |
|
|
You need GCC update as well and that has only just been committed to gcc8. They are looking at backporting to 7.
Spectre was the real problem and cannot actually be fixed (5years maybe) but can be mitigated
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 15, 2018 7:25 am Post subject: |
|
|
| Naib wrote: | | You need GCC update as well and that has only just been committed to gcc8 |
My problem with understanding here is that the retpoline technique does not appear to require any new instruction (i.e. it should not require a microcode upgrade). Does gcc use another (preferable?) technique by requiring the new instruction (microcode upgrade)? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jan 15, 2018 8:12 am Post subject: |
|
|
That's because there are two variants of spectre
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 15, 2018 8:46 am Post subject: |
|
|
| Naib wrote: | | That's because there are two variants of spectre |
Thanks for the clarification. So do I understand correctly that the gcc patch is against both, #1 and #2, one using retpoline and the other using the new instruction?
If I understand correctly, https://github.com/Eugnis/spectre-attack only exploits one of these two; does anybody know a public exploit for the other? This would be useful for testing if the gcc patch is finally released to check whether the microcode patch really works.... |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Jan 15, 2018 9:15 am Post subject: |
|
|
uCode update does not imply "new instructions". The core of CISC chips is more akin to a RISC architecture. A uCode update could be associated with a pre-existing CISC instruction but the low-level RISC is re-ordered.
uCode update could be more than enough to "mitigate" Spectre (variant 1 &2) & if you think about windows... there is no update to Microsoft compiler.
So if a uCode update could be enough why go to all the hassle of modifying GCC? because the uCode is just a mitigation, gcc is equally just a mitigation, uCode+gcc is still just a mitigation BUT with increased coverage. Equally Intel have only stated they are "patching" product up to 5years YET this failed concept goes all the way back to the Core2 chips... how do you protect those machine running EoL CPU's without some OS-level mitigation.
Now the uCode update could expose a new opcode but I doubt it. The errata for the CPU's would need to be read and specifics of the gcc machine code viewed
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Mon Jan 15, 2018 11:41 am Post subject: |
|
|
| pjp wrote: | | PrSo wrote: | | pjp wrote: |
That sounds to me like CONFIG_PAGE_TABLE_ISOLATION should be enabled for AMD processors. Or at least not setting it with the knowledge of leaving the vulnerability exposed. |
So it seems that even if you compile kernel with CONFIG_PAGE_TABLE_ISOLATION=Y PTI is auto-disabled on AMD cpu anyway. |
But the underlying issue is still whether or not AMD should have it enabled. From the prior information, the answer appears to be yes.
To enable the functionality, I had to enable the kernel option AND enable it on the kernel command line with "pti=on". After that (and only after that): | Code: | dmesg |grep -i isol
[ 0.000000] Kernel/User page tables isolation: force enabled on command line.
[ 0.000000] Kernel/User page tables isolation: enabled |
(I got the idea from Naib's post on page 5 of this thread which referenced "pti=off". Thanks Naib!) |
I think that you are playing here the advocatus diaboli role.
With the knowledge that the test case provided on wiki page was performed in 2013, and should be mitigated by KAISER (now PTI) I personally think that AMD statement to which you got link in mike155 post is still in power, of course with the assumption that AMD is aware of that vulnerability.
| Thomas Lendacky wrote: | | AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. |
I know that this could be some kind of uncomfortable situation but there is nothing more we can do for now than to trust AMD with that. Maybe someone will write PoC on that case in the near future proofing that AMD was duly diligent.
If you think different on that subject please feel free to contact AMD an ask them to resolve your possible concerns.
Last edited by PrSo on Mon Jan 15, 2018 1:16 pm; edited 2 times in total |
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 203
|
| Posted: Mon Jan 15, 2018 12:19 pm Post subject: |
|
|
| mv wrote: | | Versions for my cpu have been updated, but (unsurprisingly) https://github.com/Eugnis/spectre-attack still renders the machine as exploitable (though I didn't check whether it tests spectre #1 or #2). |
That PoC is for spectre #1, the new microcode is for mitigating spectre #2.
| mv wrote: | | ("unsurprisingly", because it was announced somewhere that these 2 cannot be fixed by microcode). |
None of these vulnerabilities can be fixed with microcode updates alone. If they could Intel and AMD would have done so. Spectre #2 can be mitigated by the new functionality the microcode introduce if the operating system use that functionality. This requires both the microcode and updates to the kernel.
| mv wrote: | | And meltdown (i.e. #3) is fixed by pti in the kernel, isn't it? |
Yes... well it's mitigated by pti.
| mv wrote: | | Somewhere it was announced that the microcode updates are necessary to make the upcoming compiler patches work |
No, the compiler patches (retpoline support) is independent of the microcode. If a program is compiled with retpolines an evil program can't use spectre #2 to read that program's memory. So if the kernel is compiled with retpolines regular programs can't read the kernel memory, but they can still read each others memory and BIOS/UEFI memory. If all programs and the kernel are compiled with retpolines an evil program could only read BIOS/UEFI memory but that's bad enough. There might also be closed source programs that can't be recompiled. The microcode makes it possible for the kernel to flush the state of the branch predictor on context switches so that evil programs can't influence speculative execution of other programs. That is needed to protect the BIOS and closed source programs but it has higher overhead than just retpolines. Retpolines also don't work at all on recent Intel cpus like Skylake so the microcode update is a must there. At least that is how I understand it.
| mv wrote: | | (and also how to check whether my updated version really contains the "mitigations" whatever they are, e.g. whether the new instruction has been added...) |
https://forums.gentoo.org/viewtopic-p-8167514-highlight-.html#8167514
This post show how to check your microcode. |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Mon Jan 15, 2018 2:52 pm Post subject: |
|
|
| pjp wrote: | | Naib wrote: | Exactly...
Part of me groaned when that "checker" was being used around this place... it just checks the main mitigations are in-place. This in itself is a good check BUT if you really want to be sure you need to run the PoC code |
What makes random C code on github which requires root access trustworthy?
| kajzer wrote: | | But to write a PoC and need that.... maybe I got things wrong but I thought the whole point of this exploits/bugs is that you can read kernel memory from userland, reading it from root ... I don't see a point. |
Well, isn't one of the primary warnings to not run untrustworthy code? |
Graz University of Technology is not exactly a "random" source. Look at code or have someone who can, it does not do anything beyond what's documented . This was my point with those other projects, why trust? and root is required to make it easier. you can just plug in the KASLR offset yourself and attack your own software and never use root. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 15, 2018 3:04 pm Post subject: |
|
|
Greg Kroah-Hartman just posted new stable previews for kernels 4.9 and 4.14. The patches include retpoline support - so let's start testing 
There are two kernel .config options:
| Code: | CONFIG_RETPOLINE=y
CONFIG_PAGE_TABLE_ISOLATION=y |
and the kernel parameters listed below (see 'Documentation/admin-guide/kernel-parameters.txt'):
| Code: | pti=<value>
nopti
spectre_v2=<value>
nospectre_v2
|
There are also some new sys files (see 'Documentation/ABI/testing/sysfs-devices-system-cpu'):
| Code: | /sys/devices/system/cpu/vulnerabilities/meltdown
/sys/devices/system/cpu/vulnerabilities/spectre_v1
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
The file 'Documentation/x86/pti.txt' contains a large amount of useful information.
I booted kernel 4.14.14-rc1 with default parameters (no Spectre or Meltdown parameters):
| Code: | # dmesg | egrep "(isolation|Spectre)"
[ 0.000000] Kernel/User page tables isolation: enabled
[ 0.011967] Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline
# cd /sys/devices/system/cpu/vulnerabilities/*
# for file in *; do echo "$file : $(tail -n1 $file)"; done
meltdown : Mitigation: PTI
spectre_v1 : Vulnerable
spectre_v2 : Vulnerable: Minimal generic ASM retpoline
|
That's a little less than expected... |
|
| Back to top |
|
|
Hossie
Tux's lil' helper
Joined: 08 Dec 2005
Posts: 116
|
| Posted: Mon Jan 15, 2018 5:55 pm Post subject: |
|
|
That doesn't seem to be "new", this is how a fedora kernel already looks like:
| Code: | [root@jenkins vulnerabilities]# pwd
/sys/devices/system/cpu/vulnerabilities
[root@jenkins vulnerabilities]# ls -l
total 0
-r--r--r--. 1 root root 4096 Jan 15 18:53 meltdown
-r--r--r--. 1 root root 4096 Jan 15 18:53 spectre_v1
-r--r--r--. 1 root root 4096 Jan 15 18:53 spectre_v2
[root@jenkins vulnerabilities]# cat *
Mitigation: PTI
Vulnerable
Vulnerable: Minimal generic ASM retpoline |
| Code: | [root@jenkins vulnerabilities]# uname -r
4.14.13-300.fc27.x86_64 |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 6:00 pm Post subject: |
|
|
mike155,
retpoline support can be done by hand in the assembler portions of the kernel.
For the C code, it requires a retpoline aware compiler.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 15, 2018 6:16 pm Post subject: |
|
|
| Hossie wrote: | | That doesn't seem to be "new", this is how a fedora kernel already looks like: |
Yes, Fedora and RHEL seem to be ahead. I already saw it here.
I really wonder what is going on here. Kernel developers made many changes to the Spectre patchset until yesterday - so how can Red Hat and Fedora kernels already include the Spectre patchset? The only explanation that comes to my mind is that Red Hat included an earlier and probably incomplete version of the patchset into their kernels. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 15, 2018 6:25 pm Post subject: |
|
|
| NeddySeagoon wrote: | retpoline support can be done by hand in the assembler portions of the kernel.
For the C code, it requires a retpoline aware compiler. |
You are probably right! So we will have to wait!  |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 15, 2018 7:11 pm Post subject: |
|
|
It seems that GCC 7.3 with Spectre mitigation patches will be released soon. Richard Biener wrote:
| Quote: | I plan to do GCC 7.3 RC1 on Wednesday now with the final release about a week later if no issue shows up.
|
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jan 15, 2018 8:39 pm Post subject: |
|
|
| Naib and tholin, thank you very much for the helpful explanations. |
|
| Back to top |
|
|
Hossie
Tux's lil' helper
Joined: 08 Dec 2005
Posts: 116
|
| Posted: Mon Jan 15, 2018 8:45 pm Post subject: |
|
|
| mike155 wrote: | It seems that GCC 7.3 with Spectre mitigation patches will be released soon. Richard Biener wrote:
| Quote: | I plan to do GCC 7.3 RC1 on Wednesday now with the final release about a week later if no issue shows up.
|
|
So we all have to go ~arch on GCC?  |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 8:52 pm Post subject: |
|
|
Hossie,
How lucky do you feel?
The patches are there now.
Personally, I don't feel confidenh enough to run a -9999 gcc.
_________________
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 8:56 pm Post subject: |
|
|
| NeddySeagoon wrote: | Hossie,
How lucky do you feel?
The patches are there now.
Personally, I don't feel confidenh enough to run a -9999 gcc. |
why not? you have been running a 9999 CPU for the last couple of decades 
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Hossie
Tux's lil' helper
Joined: 08 Dec 2005
Posts: 116
|
| Posted: Mon Jan 15, 2018 9:56 pm Post subject: |
|
|
I didnt mean 9999, i just meant using the ~amd64 (testing) GCC 7.3 when its released. Still it will probably be ~arch for a while so to have a fix you have to live with a ~arch GCC for now I assume.  |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Mon Jan 15, 2018 9:58 pm Post subject: |
|
|
Hossie,
That will be correct. Unless you run all ~arch anyway
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9678
Location: almost Mile High in the USA
|
| Posted: Mon Jan 15, 2018 11:11 pm Post subject: |
|
|
Hooboy, the upgrade from gcc 4.9.4 -> 7.3.??? in one step is going to be "fun" ...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mno
Guru
Joined: 29 Dec 2003
Posts: 454
Location: Toronto, Canada
|
| Posted: Mon Jan 15, 2018 11:13 pm Post subject: |
|
|
I did 4.9.4 to 6.4.0 and that went generally well. I guess if you want, do a -> 6.40 (with profile upgrade to 17) before going further.
_________________
"Hello and goodbye. As always." | You can't use here?? | Unanswered |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 592
Location: Australia
|
| Posted: Tue Jan 16, 2018 1:03 am Post subject: |
|
|
| mno wrote: | | I did 4.9.4 to 6.4.0 and that went generally well. |
My reqular emerge installed 6.4.0 on Sunday, other than having to process a bunch of preserved rebuilds I wouldn't have noticed.
Edit to say: so for that reason alone, I'd just do the interim step on non-exotic systems. |
|
| Back to top |
|
|
mno
Guru
Joined: 29 Dec 2003
Posts: 454
Location: Toronto, Canada
|
| Posted: Tue Jan 16, 2018 2:02 am Post subject: |
|
|
| ian.au wrote: | | mno wrote: | | I did 4.9.4 to 6.4.0 and that went generally well. |
My reqular emerge installed 6.4.0 on Sunday, other than having to process a bunch of preserved rebuilds I wouldn't have noticed.
Edit to say: so for that reason alone, I'd just do the interim step on non-exotic systems. |
Did you also switch to profile 17?
_________________
"Hello and goodbye. As always." | You can't use here?? | Unanswered |
|
| Back to top |
|
|
|
Kernel & Hardware
