Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

[mv]

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...

[Naib]

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

[mv]

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)?

[Naib]

That's because there are two variants of spectre

[mv]

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....

[Naib]

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

[PrSo]

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: Select all

 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.

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.

[tholin]

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.

("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.

And meltdown (i.e. #3) is fixed by pti in the kernel, isn't it?

Yes... well it's mitigated by pti.

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.

(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-8 ... ml#8167514
This post show how to check your microcode.

[blopsalot]

This project is the only PoC/test I found that's not garbage.
https://github.com/IAIK/meltdown

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?

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.

[mike155]

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: Select all

CONFIG_RETPOLINE=y
CONFIG_PAGE_TABLE_ISOLATION=y

and the kernel parameters listed below (see 'Documentation/admin-guide/kernel-parameters.txt'):

Code: Select all

pti=<value>
nopti
spectre_v2=<value>
nospectre_v2

There are also some new sys files (see 'Documentation/ABI/testing/sysfs-devices-system-cpu'):

Code: Select all

/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: Select all

# 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...

[Hossie]

That doesn't seem to be "new", this is how a fedora kernel already looks like:

Code: Select all

[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: Select all

[root@jenkins vulnerabilities]# uname -r
4.14.13-300.fc27.x86_64

[NeddySeagoon]

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.

[mike155]

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.

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

You are probably right! So we will have to wait!

[mike155]

It seems that GCC 7.3 with Spectre mitigation patches will be released soon. Richard Biener wrote:

I plan to do GCC 7.3 RC1 on Wednesday now with the final release about a week later if no issue shows up.

[mv]

Naib and tholin, thank you very much for the helpful explanations.

[Hossie]

It seems that GCC 7.3 with Spectre mitigation patches will be released soon. Richard Biener wrote:

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?

[NeddySeagoon]

Hossie,

How lucky do you feel?
The patches are there now.

Personally, I don't feel confidenh enough to run a -9999 gcc.

[Naib]

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

[Hossie]

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.

[NeddySeagoon]

Hossie,

That will be correct. Unless you run all ~arch anyway

[eccerr0r]

Hooboy, the upgrade from gcc 4.9.4 -> 7.3.??? in one step is going to be "fun" ...

[mno]

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.

[ian.au]

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.

[mno]

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?