Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

[ian.au]

Yes, but that was before the gcc switch, back in early Dec I think.

[Naib]

Intel Warns Its Patches for Chip Flaws Are Buggy

One Intel partner familiar with the document said it is problematic the company is only notifying select customers they should hold off on the patches. The public has “been given the microcode update but has not been given the important technical information that Intel recommends that you don’t use this,” the partner said.

So Yer.. back to my previous statement about Intel iCode...

[VinzC]

Hi guys, sorry for hijacking this thread — I haven't delved into it thoroughly but I am wondering if my CPUs will receive fixes. In my laptop is an Ivy Bridge (Intel Core i3-3000), serial number=000306A9 and I can't find it in the Gentoo Meltdown & Spectre info pages. From what I've read in this thread (or was it elsewhere?) Intel would only "fix" (i.e. release updated microcode for) CPUs made during the last 5 years or so, is that correct?

[krinn]

The info i'm sure about intel release of microcode so far:
- intel said they will release update fix fast (and they did for some) for most cpu made < 5 years
- since the documentation was written, intel has release more microcode (which may include your cpu, you should check latest microcode update)
- intel has also confirm a bug with "haswell" (i don't remember other cpu, but i own an haswell, might be why i remember this one) microcode (the 0x23 early release with fix for the spectre#2) is buggy and face reboot using it.
- intel didn't say anything about cpu past +5 years (which also mean, they didn't say they won't, but they suggest priority on <5years, which "should" imply also fix for +5 years)

[Naib]

The info i'm sure about intel release of microcode so far:
- intel said they will release update fix fast (and they did for some) for most cpu made < 5 years
- since the documentation was written, intel has release more microcode (which may include your cpu, you should check latest microcode update)
- intel has also confirm a bug with "haswell" (i don't remember other cpu, but i own an haswell, might be why i remember this one) microcode (the 0x23 early release with fix for the spectre#2) is buggy and face reboot using it.
- intel didn't say anything about cpu past +5 years (which also mean, they didn't say they won't, but they suggest priority on <5years, which "should" imply also fix for +5 years)

you missed: Intel kept it from the public that the updated ucode should not be used (but informed their strategic partners)

[mike155]

- intel said they will release update fix fast (and they did for some) for most cpu made < 5 years

That's NOT what they said. They said 'introduced', not 'made'. This difference is important for Ivy Bridge CPUs. Many of those CPUs were manufactured or sold within the last 5 years. But unfortunately, they were introduced Q2'12.

[VinzC]

Thanks krinn et al. That doesn't sound too reassuring though. I keep the panic button nearby, just in case

[krinn]

you missed: Intel kept it from the public that the updated ucode should not be used (but informed their strategic partners)

I haven't said too that my haswell is not suffering from the reboot bug, while using 0x23.
Affected "partners" may use something i still doesn't have (like a fucking kernel with proper fix or something) that trigger the reboot bug.

[mv]

I haven't said too that my haswell is not suffering from the reboot bug, while using 0x23

I haven't experienced any problems with it, either, so far.

[krinn]

I haven't said too that my haswell is not suffering from the reboot bug, while using 0x23

I haven't experienced any problems with it, either, so far.

Just adding it for clarity -> https://newsroom.intel.com/news/intel-s ... ot-issues/
Looks like i forget broadwell with haswell.

[mno]

More broad article on the microcode side of things:
https://arstechnica.com/gadgets/2018/01 ... et-closer/

[kavra]

I haven't said too that my haswell is not suffering from the reboot bug, while using 0x23

I haven't experienced any problems with it, either, so far.

I haven't experienced any problems with it, either,...important: so far...

[PrSo]

It seems that PTI is going to be backported to x86-32, but still WIP:
https://lkml.org/lkml/2018/1/16/668

[krinn]

More broad article on the microcode side of things:
https://arstechnica.com/gadgets/2018/01 ... et-closer/

and Intel is currently recommending that people cease installing a microcode update it issued to help tackle the Spectre problem.

That's not what i have saw, nor anything sane to do!
From the intel article which indeed report the problem you can read

End-users should continue to apply updates recommended by their system and operating system providers.

So despite you might end up with the reboot bug, it's something you should still apply.
In the meantime (like some has said, including me), if only the reboot bug is affecting some "partners", it could mean the microcode update in itself isn't bad ; maybe something those partners has done is the problem when interacting with the new microcode (someone has report Redhat is known to use real early patches in their kernels).

Anyway enough guessing: Do apply microcode update, and at least see if you have the reboot bug.
And if you have the reboot bug, well, no idea because you are facing impossible choice for a user: "running insecure server stable" <> "running secure but rebooting server".
The only logical and safe choice for big companies is this one: use microcode updates on a cpu not from the affected category -> no server with haswell and broadwell, but another cpu which do have microcode update.
Alas that's a choice those companies have, a choice few users will have.

But the hint on that article is so wrong because it assume everybody will reboot and pickup the : "don't apply the microcode update and run insecure and stable" without balancing against "maybe you won't get reboot bug, and could then run a secure stable server".
And it is also wrong because the article is claiming Intel has said that, which is false from what i have read myself, or could be true, but the article just lack to provide a link to this.

[Elleni]

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.

Mhm, now what is officially recommended on amd ryzen boxes ? Ehable CONFIG_PAGE_TABLE_ISOLATION=Y PTI and as its autodisabled by default enable it on the kernel command line with "pti=on" ? Or is this not required ?

[Spargeltarzan]

Does somebody read about a release date for Gcc 7.3 with retpoline? (Phoronix Link )

They write reptoline is merged already into it and it will be released in "a few weeks" where gcc 8 is released in March/April

[mike155]

Does somebody read about a release date for Gcc 7.3 with retpoline? (Phoronix Link)

They write reptoline is merged already into it and it will be released in "a few weeks"

You'll get more accurate information if you read GCC mailing lists: https://gcc.gnu.org/ml/gcc-patches/2018 ... 01303.html

[Wallsandfences]

I must confirm that loading amd microcode and having retpoline enabled in 4.14.14-gentoo does not prevent spectre-attack-master being succesful. Is this to be expected?

[NeddySeagoon]

Wallsandfences,

retpolines are in two phases.
1) in the kernel assembly code. They are fixed in 4.14.
2) In the kernel C code. That needs a retpoline aware compiler. Watch out for a version bump to gcc. 6.x or 7.y, since it has to come from upstream.

[mike155]

A release candidate for GCC 7.3 is available: https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html.

The final release of GCC 7.3 is scheduled for Wednesday, January 24th.

EDIT: The link to snapshot given in the mail above doesn't seem to work. The correct link seems to be: https://gcc.gnu.org/pub/gcc/snapshots/7 ... -20180117/

[mike155]

I installed gcc-7.3.0-RC-20180117, compiled Linux kernel 4.14 and rebooted.

Code: Select all

# dmesg -t | grep gcc
Linux version 4.14.14 (root@xxx) (gcc version 7.2.1 20180117 (GCC)) #2 SMP Thu Jan 18 19:07:37 CET 2018

# dmesg -t | egrep "(isolation|Spectre)"
Kernel/User page tables isolation: enabled
Spectre V2 mitigation: Mitigation: Full generic 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 : Mitigation: Full generic retpoline

Mitigation: Full generic retpoline - that's what I wanted to see! Much better than my last result.

[Thistled]

Hi guys, sorry for hijacking this thread — I haven't delved into it thoroughly but I am wondering if my CPUs will receive fixes. In my laptop is an Ivy Bridge (Intel Core i3-3000), serial number=000306A9 and I can't find it in the Gentoo Meltdown & Spectre info pages. From what I've read in this thread (or was it elsewhere?) Intel would only "fix" (i.e. release updated microcode for) CPUs made during the last 5 years or so, is that correct?

VinzC, looks like you might have missed the announcement from Intel's CEO.
https://newsroom.intel.com/news-release ... st-pledge/

By Jan. 15, we will have issued updates for at least 90 percent of Intel CPUs introduced in the past five years, with updates for the remainder of these CPUs available by the end of January. We will then focus on issuing updates for older products as prioritized by our customers.

Just need to keep your fingers crossed, because "prioritised by our customers" may not slice the cake for us older CPU freaks.

(Dual-Core E5400 here - which works great)

[Hossie]

Does anyone know about upstream fixes for Spectre V1? And what will be required for that? A GCC Update and a kernel recompile?

[Ska`]

Does anyone know about upstream fixes for Spectre V1? And what will be required for that? A GCC Update and a kernel recompile?

I think a kernel recompile will be enough, I just upgraded to 4.14.14 and the tool says:

Code: Select all

STATUS:  VULNERABLE  (only 51 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

Previous 4.14.13 had a much lower opcodes number.

For v2 you need CONFIG_RETPOLINE (available from 4.14.14) and a new GCC (not available yet), then a simple emerge -e world with your new&slower CPU

[eccerr0r]

For v2 you need CONFIG_RETPOLINE (available from 4.14.14) and a new GCC (not available yet), then a simple emerge -e world with your new&slower CPU :D

I was thinking I should keep two versions of the kernel, one secured, one insecure - and use the insecure one to emerge -e world when the machine is airgapped :D