# Meltdown and Spectre for Noobs

## while true

Hello Gentoo people,

Blame authors of Gentoo Handbook and this forum's community 

for allowing noobs like me to install Gentoo 

and bother you with following questions and stealing your time.

That said, as noob, I am grateful for Gentoo Handbook and especially this community!

I work in a warehouse so I have weekend to make nice with Gentoo:

```
>$ uname -a

Linux keeshta 4.0.5-gentoo #19 SMP Wed Oct 7 16:25:30 CEST 2015 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux

>$ emerge -uDNa @world

!!! Your current profile is deprecated and not supported anymore.

!!! Use eselect profile to update your profile.

!!! Please upgrade to the following profile if possible:

        default/linux/amd64/17.0/desktop

You may use the following command to upgrade:

        eselect profile set default/linux/amd64/17.0/desktop

These are the packages that would be merged, in order:

...

...

...

!!! The following installed packages are masked:

- sys-kernel/gentoo-sources-4.14.8-r1::gentoo (masked by: package.mask)

/usr/portage/profiles/package.mask:

# Alice Ferrazzi <alicef@gentoo.org> (05 Jan 2018)

# kernel: Meltdown and Spectre - Processor flaw. (#643228)

# Please upgrade for Intel processor flaw workaround

# (currently KPTI patch are 64bit only),

# also excluding AMD from the fix as not affected.

# Please unmask your kernel version if you want to

# continue to use your kernel with AMD.

# Removal in a month.
```

I gathered that bug is hardware thingy, 

and software patches slow down performance, 

and that is all I understand.

As always, I can copy and paste like a pro, but what?

So here I ask you kindly to help yours eternal noob for tip or two.

Thank you.

----------

## NeddySeagoon

while true,

These things are information leaks.  Of themselves, they are not direct threats to your system security.

However, the information that can be leaked might aid a privilege escalation attack.

That is, it could leak your root password in clear text.

You would need to be running software that included one or more of the information leak exploits.

The leaked information would then need to be used in an attack.

You do need to fix it.  How fast depends on how much you trust your users (including remote users) and your installed software base.

----------

## while true

Hey NeddySeagoon, thank you for your prompt reply,

I am the only user, and my base apps are, well, like I know what I have, but I do have ff, evince, libre and such, smplayer...

So, I have to select my profile first, than I go and unmask gentoo-sources, and that should do the trick?

Thank you

----------

## NeddySeagoon

while true,

The patch set is not yet complete.

You may need a CPU microcode update too.

If you are going to apply the available fixes today, be aware that there will be more soon.

-- edit --

None of this is related to the Gentoo profile change.  Do the changes separately.

Profile first, since that will give you a new gcc and you want all the parts of the kernel built with the same gcc.

Then do the security updates.

----------

## krinn

 *while true wrote:*   

> I am the only user

 

alas that is not enough to secure yourself, as information could be leak from browser.

how much you judge the severity of a forged website, leaking your bank account and password to use your bank account from your browser?

please refer to https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre

----------

## mrbassie

So am I understanding correctly that kpti + microcode is what/all we currently have to mitigate these?

----------

## krinn

 *mrbassie wrote:*   

> So am I understanding correctly that kpti + microcode is what/all we currently have to mitigate these?

 

yes

or that  :Smile: 

----------

## mrbassie

Cool, I've already done both. I'll continue to keep an eye on the news.

----------

## while true

Hello Gentoo people,

Sorry for delayed response, I just got from work, and yesterday was getting late as I read krinn's link (krinn, oh, i know you are trying to help, thank you, but as a noob I was hoping for something else, let me use those emoji to express my state:   :Evil or Very Mad:   )...

So word "mitigate" has poped up couple of times, and I have no printed dictionary, and online one's is not understandible to me, so first, does mitigate means to, like, "ease the pain"?

And the rest of article... I understand the words, but I can not get the meanning...

I gathered that I have to look out for linux-firmware (amd cpu), that is the microcode, right?

I have old kernel, I am still not familliar with updating it, and still have gentoo-sources 4.0.5, if I need to add things to kernel.

Linux-firmware will work only with gentoo-sources 4.4.110 and newer (it has kernel patch, something to do with size), so, do I need to update kernel as well?

And at the end of amd section there is link to HowTo apply microcode, but page is for intel...

Also I use vpn, and that requires qemu package, which should be updated by regular emerge -uDN @world, right?

And what on pale blue dot is KPTI?

I must tell you, I have a big questionmark over my head, and I am having my first glass of white wine, but, last question, would it be easier for noob to go for fresh install, where all those updates are included, than to bother you guys and steal your time?

NeddySeagoon, I will change profile on the morrow, thank you for separating the two.

Thank you

----------

## NeddySeagoon

while true,

Mitigate means to "reduce the effects of" so "ease the pain" is a pretty good approximation.

You will need to update to a kernel that has had the patches backported.  That's a recent 4.14 kernel.

The patches are also in 4.15.0 but that's still not released, it a release-candidate.

KPTI flushes the kernel page table every context switch, so that information is not leaked between the kernel and user space.

This is a new kernel configuration option in 4.15.0 that has been back ported to later 4.14 kernels.

You need a kernel with that option and you need to set the option on.

This is only a part of the fix.  You will also need a microcode update.

Even with the microcode update and the KPTI optin in newer kernels, there is still more to do.

Not all the threats are yet addressed.

Like a pain killer, these mitigations come with a price. Performance is reduced.

There will be more changes in the coming weeks.

----------

## roboto

I have AMD Turion 64 x2 from 2007. Is it affected by Spectre and the three variants of Meltdown?

----------

## NeddySeagoon

roboto,

There are some tests out there.  Try it.

----------

## fedeliallalinea

 *roboto wrote:*   

> I have AMD Turion 64 x2 from 2007. Is it affected by Spectre and the three variants of Meltdown?

 

https://forums.gentoo.org/viewtopic-p-8168584.html#8168584

https://forums.gentoo.org/viewtopic-p-8167424.html#8167424

----------

## while true

Good evening Gentoo people,

Oi oi Neddy, so this spectre and meltdown (or S&M, khehe) brought me to upgrade kernel for the first time, took me over 4 hours this morning, but:

```
Linux keeshta 4.14.8-gentoo-r1 #1 SMP Sat Jan 13 12:30:09 CET 2018 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
```

I can't wait for 4.15  :Wink: 

So grep did not find KPTI in /usr/src/linux/.config:

```
# grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :("

unpatched :(

# cat /boot/config-4.14.8-gentoo-r1 | grep CONFIG_PAGE_TABLE_ISOLATION

#

# cat /boot/config-4.14.8-gentoo-r1 | grep kpti

# 

# cat /boot/config-4.14.8-gentoo-r1 | grep KPTI

#
```

Is there something I missed? There should be kpti in kernel now?

I have long night ahead, not just because it is orthodox new year's eve, but I have dozen of big emerge things, including linux-firmware (that is the microcode, right?) so I will report in the morning (technically next year) but for now:

```
# ./spectre-meltdown-checker.sh 

Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.14.8-gentoo-r1 #1 SMP Sat Jan 13 12:30:09 CET 2018 x86_64

CPU is AMD FX(tm)-8350 Eight-Core Processor

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

* Checking count of LFENCE opcodes in kernel:  NO 

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

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

* Mitigation 1

*   Hardware (CPU microcode) support for mitigation:  NO 

*   Kernel support for IBRS:  NO 

*   IBRS enabled for Kernel space:  NO 

*   IBRS enabled for User space:  NO 

* Mitigation 2

*   Kernel compiled with retpoline option:  NO 

*   Kernel compiled with a retpoline-aware compiler:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

* Kernel supports Page Table Isolation (PTI):  NO 

* PTI enabled and active:  NO 

> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
```

Until next year, thank you

----------

## elko

 *while true wrote:*   

> 
> 
> Oi oi Neddy, so this spectre and meltdown (or S&M, khehe) brought me to upgrade kernel for the first time, took me over 4 hours this morning, but:
> 
> 

 

How did you upgrade your kernel? Did you updated your .config? See https://wiki.gentoo.org/wiki/Kernel/Upgrade#.config_file

----------

## Naib

 *roboto wrote:*   

> I have AMD Turion 64 x2 from 2007. Is it affected by Spectre and the three variants of Meltdown?

 

There are 3 variants. 2 are spectre and ONE is meltdown

KPTI stops meltdown,

Retpoline + microcode mitigates spectre

----------

## while true

Good morning Gentoo people,

Hey elko, yes, I updated old .config with make silentoldconfig, that took hours to read and answer. I was on the lookout for kpti or CONFIG_PAGE_TABLE_ISOLATION, but I missed it. Also with make menuconfig, under Security Options I can not find it. Is it called by different name?

Firmware-linux, I remember that package now, I needed it for my radeon graphich card, I had to write in a list of cards in kernel via make menuconfig. I guess it was removed in the past, since it was brought back last night with emerge -uDN @world.

but still:

```
# ./spectre-meltdown-checker.sh

Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.14.8-gentoo-r1 #1 SMP Sat Jan 13 12:30:09 CET 2018 x86_64

CPU is AMD FX(tm)-8350 Eight-Core Processor

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

* Checking count of LFENCE opcodes in kernel:  NO 

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

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

* Mitigation 1

*   Hardware (CPU microcode) support for mitigation:  NO 

*   Kernel support for IBRS:  NO 

*   IBRS enabled for Kernel space:  NO 

*   IBRS enabled for User space:  NO 

* Mitigation 2

*   Kernel compiled with retpoline option:  NO 

*   Kernel compiled with a retpoline-aware compiler:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

* Kernel supports Page Table Isolation (PTI):  NO 

* PTI enabled and active:  NO 

> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
```

Am I to wait for further updates?

Thank you

----------

## NeddySeagoon

while true,

Happy new year!

Your 4.14.8-gentoo-r1 kernel is still too old.

There is a Gentoo Wiki Page

That page should be updated as kernel patches are added to gentoo-sources, so I won't quote it here.

----------

## Fitzcarraldo

 *while true wrote:*   

> So grep did not find KPTI in /usr/src/linux/.config:
> 
> ```
> # grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :("
> 
> ...

 

Off Topic: while true, just for information, you don't need to use two grep commands to find lower-case and upper-case variants of the same string, the following single command would do it:

```
cat /boot/config-4.14.8-gentoo-r1 | grep -i kpti
```

which can be simplified even further:

```
grep -i kpti /boot/config-4.14.8-gentoo-r1
```

From 'man grep':

 *Quote:*   

>  -i, --ignore-case
> 
>               Ignore case distinctions, so that characters that differ only in case match each other.

 

----------

## while true

Good afternoon Gentoo people,

Hey NeddySeagoon, thank you, and happy new year to you too!

(before I forget, yesterday when I upgraded kernel to 4.14.8 on reboot I noticed (i have 2 monitors) that my right monitor was inversed in colour, as in white background and grey font colour. Now, with 4.14.13 is the same inversion. That stops once I go startx. How can I go about this?)

I licenced, ~amded and unmasked gentoo-sources, and emerge offered latest gentoo-sources: 

```
# uname -a

Linux keeshta 4.14.13-gentoo #1 SMP Sun Jan 14 15:16:43 CET 2018 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
```

YES! I am upgragind kernel as pro!  :Wink: 

As Fitzcarraldo suggested:

```
# grep -i kpti /boot/config-4.14.13-gentoo 

#
```

and:

```
# grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :(" 

CONFIG_PAGE_TABLE_ISOLATION=y

patched :)

#
```

and still:

```
# ./spectre-meltdown-checker.sh 

Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.14.13-gentoo #1 SMP Sun Jan 14 15:16:43 CET 2018 x86_64

CPU is AMD FX(tm)-8350 Eight-Core Processor

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'

* Checking count of LFENCE opcodes in kernel:  NO 

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

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'

* Mitigation 1

*   Hardware (CPU microcode) support for mitigation:  NO 

*   Kernel support for IBRS:  NO 

*   IBRS enabled for Kernel space:  NO 

*   IBRS enabled for User space:  NO 

* Mitigation 2

*   Kernel compiled with retpoline option:  NO 

*   Kernel compiled with a retpoline-aware compiler:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

* Kernel supports Page Table Isolation (PTI):  YES 

* PTI enabled and active:  NO 

> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer
```

```
# eix linux-firmware

[I] sys-kernel/linux-firmware

     Available versions:  20170314 ~20171206 ~20180103 20180103-r1 **99999999 {savedconfig}

     Installed versions:  20180103-r1(12:15:05 AM 01/14/2018)(-savedconfig)

     Homepage:            https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git

     Description:         Linux firmware files
```

no "ease of pain"...

I guess that is all I can do at the moment? Or can I do more?

And what should I be looking after in the coming days?

Thank you

----------

## krinn

you should just disable KPTI, it's not use because of your cpu, but lowering kernel size is never bad.

----------

## NeddySeagoon

while true,

Read this AMD page.

 *AMD wrote:*   

> Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
> 
> Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors. 
> 
> Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors. 

 

```
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'

* Kernel supports Page Table Isolation (PTI):  YES

* PTI enabled and active:  NO

> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable) 
```

PTI is in your kernel but its not needed on your CPU, so its not used. That avoids the performance penalty.

How do you load your CPU microcode?

Please put your kernel .config onto a pastebin site.  wgetpaste is your friend.

----------

## while true

Hello guys,

Like I know what I am doing, I understood I need KPTI, which comes with latest kernel, and microcode that is linux-firmware emerged.

Should I set  CONFIG_PAGE_TABLE_ISOLATION to no?

And for microcode, I just emerged it (it was in emerge -uDN @world), but I am guessing that is not enough?

I skipped Fitzcarraldo's blog on updating microcode, since from here https://wiki.gentoo.org/wiki/Radeon#Firmware it says: "However, savedconfig editing is entirely optional, those in a hurry may not want to take this route. The system will work the same, with or without the savedconfig editing."

Did I read wrong linux-firmware page?

```
wgetpaste /usr/src/linux/.config

Your paste can be seen here: https://paste.pound-python.org/show/uxavFKbFNrBmACCIWibW/
```

Thank you

----------

## NeddySeagoon

while true,

linux-firmware put the CPU microcode onto your PC.  Into /lib/firmware.

Just like you build your radeon firmware into the kernel with  

```
CONFIG_EXTRA_FIRMWARE="radeon/BTC_rlc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin radeon/CAICOS_pfp.bin radeon/CAICOS_smc.bin radeon/SUMO_uvd.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
```

, you need to build the microcode in too.

Add it to that list and rebuild your kernel.  What you have done is required but not sufficient.

With my Phenom II, I get 

```
$ dmesg | grep micro

[    2.505202] microcode: microcode updated early to new patch_level=0x010000dc

[    2.505548] microcode: CPU0: patch_level=0x010000dc

[    2.507411] microcode: CPU1: patch_level=0x010000dc

[    2.507752] microcode: CPU2: patch_level=0x010000dc

[    2.509591] microcode: CPU3: patch_level=0x010000dc

[    2.511404] microcode: CPU4: patch_level=0x010000dc

[    2.513180] microcode: CPU5: patch_level=0x010000dc

[    2.514915] microcode: Microcode Update Driver: v2.2.
```

You have a different CPU.

If you run that grep now, you will see the current microcode version.

After the kernel has the microcode built in, the version might be different.

AMD say that you don't need CONFIG_PAGE_TABLE_ISOLATION.  The kernel contains a CPU test to turn it off on AMD CPUs as its not required.

You can leave it in your kernel.

----------

## while true

Hey NeddySeagoon, thanks for sticking around

So here is the output for micro:

```
dmesg | grep micro

[    6.095070] microcode: CPU0: patch_level=0x06000817

[    6.095220] microcode: CPU1: patch_level=0x06000817

[    6.095224] microcode: CPU2: patch_level=0x06000817

[    6.095228] microcode: CPU3: patch_level=0x06000817

[    6.095232] microcode: CPU4: patch_level=0x06000817

[    6.095237] microcode: CPU5: patch_level=0x06000817

[    6.095241] microcode: CPU6: patch_level=0x06000817

[    6.095244] microcode: CPU7: patch_level=0x06000817

[    6.095269] microcode: Microcode Update Driver: v2.2.
```

Is this ok, or should I do as you suggested, like for my radeon I go to 

```
Device Drivers  --->

    Generic Driver Options  --->

        -*- Userspace firmware loading support

        [*] Include in-kernel firmware blobs in kernel binary

            (radeon/<YOUR-MODEL>.bin)

            (/lib/firmware) Firmware blobs root directory
```

and add what...?

So above takes care of vulnerability number 1 and 2, now for number 3 I need do nothing, since I have amd cpu.

But I did upgrade kernel and in security section I found Remove the kernel mapping in user mode, and I can leave it built in kernel? 

Thank you

----------

## NeddySeagoon

while true,

The microcode for meltdown/spectre for your CPU may not be out yet.

Look at 

```
ls /lib/firmware/amd-ucode/
```

 to see what is available.

Look at 

```
$ grep 'cpu fam' /proc/cpuinfo 
```

to see what you need.

With a  cpu family	: 16 CPU you would need to add 

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

----------

## while true

oi oi, so:

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

----------

## pjp

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

----------

## pjp

 *NeddySeagoon wrote:*   

> With a  cpu family	: 16 CPU you would need to add 
> 
> ```
> amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin
> ```
> ...

  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.

```
grep -m1 family /proc/cpuinfo

cpu family      : 16
```

Maybe they could have made it easier by mixing in octal as well  :Very Happy: 

Thanks.

----------

## NeddySeagoon

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.

----------

## Naib

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

 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

----------

## krinn

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

----------

## pjp

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

  Well, passing along information anyway. I thought I had just figured it out, then I saw your post  :Smile: 

----------

## pjp

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

----------

## Azurael

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

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

----------

## NeddySeagoon

Azurael,

Ask the kernel itself.

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

----------

## Azurael

 *NeddySeagoon wrote:*   

> Azurael,
> 
> Ask the kernel itself.
> 
> ```
> ...

 

That's why I asked. It just says vulnerable.

----------

## manwe_

Lack of information how to deal with all three vulnerabilities is really annoying. 

```
# 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:

```
# 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?

----------

## Jaglover

```
"-mindirect-branch=thunk"
```

Did you add it to your CFLAGS?

----------

## manwe_

Kernel adds "-mindirect-branch=thunk-extern" to make when CONFIG_RETPOLINE is turned on:

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

```

----------

## platojones

 *manwe_ wrote:*   

> Lack of information how to deal with all three vulnerabilities is really annoying. 
> 
> ```
> # grep . /sys/devices/system/cpu/vulnerabilities/*
> 
> ...

 

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

----------

## manwe_

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.

----------

## NeddySeagoon

manwe_,

Try 4.16.0-rc1 in a few weeks.

----------

## PrSo

 *manwe_ wrote:*   

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

 

or if you are brave enough:

https://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux.git/?h=nospec-v5

----------

## ct85711

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.

----------

