# Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

## luiztux

ADMIN EDIT: Please see Project:Security/Vulnerabilities/Meltdown and Spectre for details. --pjp

Hey guys, did you see this?

https://lkml.org/lkml/2017/12/4/709

https://www.google.com.br/amp/s/amp.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

----------

## Fitzcarraldo

Happened to see this article in today's Guardian (UK) newspaper:

https://www.theguardian.com/technology/2018/jan/03/major-security-flaw-found-intel-processors-computers-windows-mac-os-linux

Haven't looked around yet. Anyone know anything more, and when firmware updates -- I assume Intel will be fixing this via firmware updates -- will be available?

----------

## Myu

Not fixable by microcode   :Shocked: 

Linux 4.14.11 contains the KPTI (Kernel page table isolation) patch developped by Intel which incurs a performance hit (between 5 and 50%) to all Intel CPU users under certain workloads (syscalls will be slower)

https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

I'm not that old so this is the biggest mess I've ever seen in the IT world I guess

For reference, the kernel config option seems to be CONFIG_PAGE_TABLE_ISOLATION=y

Edit : there it is, I am on 4.14.11 ...*sigh*

```
cat /proc/cpuinfo | grep -i insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

bugs      : cpu_insecure

```

Also, nvidia-drivers-387.34 doesn't compile anymore with 4.14.11

```
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'cpu_tlbstate'

make[3]: *** [/usr/src/linux-4.14.11-gentoo/scripts/Makefile.modpost:92: __modpost] Error 1
```

----------

## eccerr0r

Lots of conflicting info out there, I think the "leak" is not a leak but accidental pseudo-privilege escalation which could result in information leakage.  This is somewhat bad... however I hope I can continue to run it the way it has been running as an option for "internal" servers.

Sounds like this affects certain CPUs and perhaps only the Core-X CPUs, unsure about P4 or older.

On the bright side, from the sound of it, if you're using 32-bit and PAE, you won't see a performance hit...

----------

## khayyam

Fitzcarraldo ... 

more detailed information on packetstorm (though the actual exploit remains undisclosed).

best ... khay

----------

## Tony0945

Watch out when updating your kernel if you have an AMD chip. Once you enable PAGE_TABLE_ISOLATION via make oldconfig you can;t turn it off with make menuconfig.

I wondered why my Athlon II was suddenly really slow launching X. I had to reboout with 4.14-10-r1 and update it again to 4.14.11 to choose "n" instead of "y" in make oldconfig.

Unless someone knows that this is needed for AMD too. Other sources on the web say this is for Intel only not AMD. But I'd like to hear it from our kernel experts.

----------

## Watcom

Apparently it affects every Intel CPU from the Pentium Pro onwards. Excluding the Pentium MMX which was released after the Pentium Pro in 1997.

AMD claims their CPUs are not affected, though we can only be sure after they disclose the actual bug details.

It looks quite serious though: 

https://twitter.com/brainsmoke/status/948561799875502080

----------

## PrSo

In the meantime:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

and

https://phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTILast edited by PrSo on Wed Jan 03, 2018 10:17 pm; edited 1 time in total

----------

## Tony0945

 *PrSo wrote:*   

> In the meantime:
> 
> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

 

P.R. damage control.

----------

## PrSo

 *Tony0945 wrote:*   

>  *PrSo wrote:*   In the meantime:
> 
> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ 
> 
> P.R. damage control.

 

exactly:

http://www.nasdaq.com/symbol/intc

----------

## 1clue

It would be really neat if they fixed the bug with gcc 6.4 and recent kernels. The combination of this bug and the backported kernels is really unfortunate right now.

----------

## Naib

 *PrSo wrote:*   

> In the meantime:
> 
> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
> 
> and
> ...

 

https://www.barrons.com/articles/amd-says-near-zero-risk-to-its-chips-1515016135

AMD Says ‘Near Zero Risk’ to Its Chips

I am playing around with rc6 to see the impact when running some large simulation BUT I am not seeing any significant degradation

 *Quote:*   

> uname -a && cat /proc/cmdline 
> 
> Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux
> 
> BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=on
> ...

 

----------

## PrSo

@Naib

agreed.

IMHO I dont think that AMD devs are lying or hiding something.

Tom Lendacky is an architect in the CPU software group on AMD and I think he knows what his statement means. 

My netbook has AMD cpu, kernel 4.14.11 from repo.

I turned PTI in kernel config off, and applied patch from LKML through 

```
/etc/portage/patches/sys-kernel/gentoo-sources/
```

lscpu or cat /proc/cpuinfo does not show any comment that my cpu is bugged.

----------

## Zephyrus

It seems that the details have now been publicly published, see for instance https://meltdownattack.com/  and https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html .

----------

## Atom2

I have just received the following Xen Security Advisory by E-Mail. In a nutshell there are three types of vulnerabilities listed, two of which are relevant for both AMD and Intel.

The third vulnerability is an Intel only issue, but, under Xen, is only relevant for 64 bit PV guests. Xen PVH and HVM guests are not affected by the third issue.

At the moment, there is no confirmed information available whether ARM is vulnerable or not.

 *Quote:*   

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Hash: SHA256
> 
>                     Xen Security Advisory XSA-254
> ...

 

Regards Atom2

----------

## PrSo

https://spectreattack.com/spectre.pdf

"Unlike Meltdown, the Spectre attack works on non-Intel processors, including AMD and ARM processors. Furthermore the KAISER patch, which has been widely applied as a mitigation to Meltdown attack, deos not protect against Spectre."

----------

## depontius

So at the moment there is no protection for Spectre?  Has anyone contacted James Bond?

----------

## Hu

Myu: as I understand it, the initial iteration declares effectively all x86 CPUs to be affected, without trying to determine false positives.  Some may not be impacted, although the speculation suggests that if you are on an Intel chip from within recent memory, you are impacted.  An AMD employee asserts on LKML that AMD is unaffected.  I have not seen any independent confirmation or refutation of that assertion.

----------

## Ralphred

 *Hu wrote:*   

> I have not seen any independent confirmation or refutation of that assertion.

 

There is a statement from AMD floating around which, at this time, says "we aren't committing to anything yet, but expect something by the end of the day" and something about waiting for researchers before commenting officially.

----------

## Ralphred

 *1clue wrote:*   

> It would be really neat if they fixed the bug with gcc 6.4 and recent kernels. The combination of this bug and the backported kernels is really unfortunate right now.

 

I appreciate anecdotal evidence is mostly useless, but just built 4.14.11 with 6.4 and it's working fine, nothing funky other than the ~amd64 for the kernel in package.use

----------

## mike155

There are 2 different types of bugs: https://spectreattack.com/

The site provides scientific papers with details.

----------

## KAMIKAZE_

Thanks, Intel, now I've made my decision: going AMD Ryzen Threadripper.

----------

## barophobia

 *Quote:*   

> Thanks, Intel, now I've made my decision: going AMD Ryzen Threadripper.

 

AMD, Intel and ARM are all effected by the spectre attack. Different attack but still scary as hell.

----------

## eccerr0r

I need to dig up my ia64 box...

----------

## Ant P.

They say there's no workaround, but there is: don't run arbitrary code off the network!

This is basic security! Everyone should have NoScript/uMatrix plus an adblocker at a bare minimum after Rowhammer.

----------

## PrSo

 *depontius wrote:*   

> So at the moment there is no protection for Spectre?  Has anyone contacted James Bond?

 

LOL,

Funny, but it could be possible that this is backfire of "Three Letter Agency's" nonexistent backdoor. But if they are so generous to share with Brits I don't know...

----------

## greyspoke

So if AMD and ARM are affected by spectre, does that mean it exposes a flaw in the instruction set they are implementing?  Or is there some shared code with a flaw in it?

----------

## gengreen

I was informed on this in freenode #musl 

As far I understand, there is 2 vulnerability :

https://meltdownattack.com

Metldown : a security patch is available at https://github.com/IAIK/KAISER/tree/master/KAISER

Spectre : There is nothing available to prevent this vulnerability.

I had a hard feeling against intel since the story with Grsecurity, now I definitively ban intel (and all thing associated with this garbage corporate) from any future purchase.

Happy new year

Edit :

 *Myu wrote:*   

> Not fixable by microcode ....
> 
> Also, nvidia-drivers-387.34 doesn't compile anymore with 4.14.11
> 
> ```
> ...

 

Don't bother yourself with CONFIG_PAGE_TABLE_ISOLATION, it won't help since your system have already a backdoor called nvidia proprietary drivers

It's like driving a motocycle with glove for the protection of your hands but no helmet.

Edit 2 :

Response of intel available here :

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

 *Quote:*   

> Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

 

At least, they have a sense of humor

----------

## Tsigorf

 *depontius wrote:*   

> So at the moment there is no protection for Spectre?  Has anyone contacted James Bond?

 

They just found a solution: https://twitter.com/attritionorg/status/948759303153856512

----------

## Myu

 *Quote:*   

> Don't bother yourself with CONFIG_PAGE_TABLE_ISOLATION, it won't help since your system have already a backdoor called nvidia proprietary drivers
> 
> It's like driving a motocycle with glove for the protection of your hands but no helmet. 

 

While I understand your point, I would like to minimize the likeliness of having a security issue, hence why I will keep KPTI enabled.

If I could purchase an AMD GPU at a decent price, I would have done it already but with the crypto mining craze, I'm holding off still.

----------

## gengreen

 *Myu wrote:*   

>  *Quote:*   Don't bother yourself with CONFIG_PAGE_TABLE_ISOLATION, it won't help since your system have already a backdoor called nvidia proprietary drivers
> 
> It's like driving a motocycle with glove for the protection of your hands but no helmet.  
> 
> While I understand your point, I would like to minimize the likeliness of having a security issue, hence why I will keep KPTI enabled.
> ...

 

There is no mention for now regarding the ibm power processor, only time will tell us if they are not affected by spectre, if you care about  security you may be more  interested by thoses processor.

Give a try to the drivers nouveau if you can 

 *Quote:*   

> 
> 
> glxgears
> 
> Running synchronized to the vertical refresh.  The framerate should be
> ...

 

It's not that bad and it is opensource.Last edited by gengreen on Thu Jan 04, 2018 12:27 pm; edited 1 time in total

----------

## yamabiko

Is it possible to provide a patch for the current stable gentoo-sources? Manually patching it on 4.9.72 gives me an hunk fail.

----------

## limn

Monocultures are always bad.

----------

## sligo

While i understand the problem, i am still a little confused. Is there something that can be done already?

----------

## Tsigorf

There is a kernel patch for Linux you can apply to avoid Meltdown (the Kaiser patch set you can find here: https://lwn.net/Articles/738975/).

However for Spectre, that's an hardware issue. I don't even know if there's a way to patch our CPUs. That's why they're telling us to replace hardware.

----------

## 1clue

 *Ralphred wrote:*   

>  *1clue wrote:*   It would be really neat if they fixed the bug with gcc 6.4 and recent kernels. The combination of this bug and the backported kernels is really unfortunate right now. 
> 
> I appreciate anecdotal evidence is mostly useless, but just built 4.14.11 with 6.4 and it's working fine, nothing funky other than the ~amd64 for the kernel in package.use

 

I would be happy as a clam with that, except my attempt panics inside the first second of boot. No logs written.

----------

## The Main Man

Smells like a ploy to buy new hardware which will then have serious backdoors and kill switches.

----------

## Watcom

Spectre needs:

A "victim" program which accepts input provided by the attacker (i.e. from the network or file). This input tricks the program to fetch cache lines based on data that is "secret".

A program running in the same processor, devised by the attacker, to collect the "secret" data by measuring the time it takes to fetch data from its own addressing space that uses the same cache lines. Fast access means the data was cached, slow means it wasn't. From this alone the secret data can be inferred by seeing which bytes of an array are fast and which are slow (e.g. first byte being fast means 'A', second byte fast means 'B' and so on. Not exactly this simple but it's the basic idea).

So as you can see not running untrusted code goes a long way in preventing Spectre attacks.

----------

## EasterParade

(?)Last edited by EasterParade on Fri Jan 05, 2018 10:08 pm; edited 1 time in total

----------

## PrSo

This is ridiculous.

I have also QNAP NAS with intel celeron on-board - (ts-251), and waiting to upgrade a firmware.

Maybe it is an exception narrowed to Ivy Bridge but KAISER patch (PTI) BRAKES kernel.

https://lkml.org/lkml/2018/1/3/864,

and

https://lkml.org/lkml/2018/1/3/105

Should I turn it off, cut of from internet and let it work only locally??

----------

## Tony0945

 *PrSo wrote:*   

> Should I turn it off, cut of from internet and let it work only locally??

 

Look at it this way - "Is it any worse than running Windoze XP & earlier?"

----------

## sligo

 *Watcom wrote:*   

> So as you can see not running untrusted code goes a long way in preventing Spectre attacks.

 

Does that include Javascript?

----------

## Naib

 *Tony0945 wrote:*   

>  *PrSo wrote:*   Should I turn it off, cut of from internet and let it work only locally?? 
> 
> Look at it this way - "Is it any worse than running Windoze XP & earlier?"

 yes because the flaw existed with those CPU's as well.  just use AMD Zen (Ryzen,threadripper)

----------

## Myu

 *Quote:*   

> There is no mention for now regarding the ibm power processor, only time will tell us if they are not affected by spectre, if you care about security you may be more interested by thoses processor.
> 
> 

 

Ah, I do care, but I can only go so deep in the rabbit hole, the more you know, the more it seems endless with stuff like Intel ME, ring -1 / -2 / -whatever and now this Spectre/Meltdown.

 *Quote:*   

> Give a try to the drivers nouveau if you can 

 

I do some Linux 3D gaming and the poor GPU already struggles with the proprietary driver, I guess nouveau will be much worse. So yeah, an AMD GPU to pair with a nice open source driver is on my whishlist for sure !

----------

## gengreen

 *transsib wrote:*   

> I remember how we chatted about major loop-holes built into the shipped hardware
> 
> more than a year ago ... for spying purposes mainly.
> 
> But theories of conspiracy plots aside if it wasn't so sad I'd  
> ...

 

I started to accept a while ago the fact that the security will always be compromised by volontary bug in anyway, even in the opensource code, they can just cover it up by "we made a mistake". Now we known for fact that the hardware is targeted as well, the war is lost.

Sadly, like snowden, assange before, this news will be covered for fews days and most of the poeple won't give a damn, even they known that their smartphone / computer or connected device spy on them all the day, they are willing to abandon their freedom for some fancy technology

Stupidity is a more dangerous enemy of the good than malice

 *Quote:*   

>  Ah, I do care, but I can only go so deep in the rabbit hole, the more you know, the more it seems endless with stuff like Intel ME, ring -1 / -2 / -whatever and now this Spectre/Meltdown. 

 

That is also true for a lot of other thing in life  :Very Happy: 

The more I learn, the less I known

----------

## pjp

 *Fitzcarraldo wrote:*   

> Happened to see this article in today's Guardian (UK) newspaper:
> 
> https://www.theguardian.com/technology/2018/jan/03/major-security-flaw-found-intel-processors-computers-windows-mac-os-linux
> 
> Haven't looked around yet. Anyone know anything more, and when firmware updates -- I assume Intel will be fixing this via firmware updates -- will be available?

  Merged this thread.

----------

## Watcom

 *sligo wrote:*   

>  *Watcom wrote:*   So as you can see not running untrusted code goes a long way in preventing Spectre attacks. 
> 
> Does that include Javascript?

 

Yes it does, unfortunately.

----------

## toofied

 *Ant P. wrote:*   

> Everyone should have NoScript/uMatrix plus an adblocker at a bare minimum after Rowhammer.

 

Definitely agree! Unfortunately, many sites now require JS to have basic usability. Wix and AngularJS come to mind. Hopefully people will start refusing to participate in websites which demand javascript for basic function...

----------

## Myu

 *Quote:*   

> Everyone should have NoScript/uMatrix plus an adblocker at a bare minimum after Rowhammer.	
> 
> Definitely agree! Unfortunately, many sites now require JS to have basic usability. Wix and AngularJS come to mind. Hopefully people will start refusing to participate in websites which demand javascript for basic function...

 

I did just that, installed µMatrix + NoScript, let's see how usable it is.

 *Quote:*   

> 
> 
> Sadly, like snowden, assange before, this news will be covered for fews days and most of the poeple won't give a damn, even they known that their smartphone / computer or connected device spy on them all the day, they are willing to abandon their freedom for some fancy technology 

 

I've no words because I know you speak the truth...  :Sad:  but having to change all my hardware because the damn Intel CPU MMU security was a lie since 20+ years... it's unbelievable.

----------

## Naib

 *toofied wrote:*   

>  *Ant P. wrote:*   Everyone should have NoScript/uMatrix plus an adblocker at a bare minimum after Rowhammer. 
> 
> Definitely agree! Unfortunately, many sites now require JS to have basic usability. Wix and AngularJS come to mind. Hopefully people will start refusing to participate in websites which demand javascript for basic function...

 umatrix does permit per site settings

----------

## EasterParade

[b]Last edited by EasterParade on Fri Jan 05, 2018 10:09 pm; edited 1 time in total

----------

## Jaglover

Generally, if a defective product is sold a recall should be done.

----------

## NightMonkey

Is there any mitigation possible, perhaps in either the kernel config, or via CFLAGs, that removes some feature that is allowing this exploitable path in our chipsets? Pretty ugly stuff - and I wonder who has been exploiting this for years without the public knowing...

----------

## PrSo

Here is part of Spectre patch:

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html

----------

## Myu

 *Quote:*   

> Is there any mitigation possible, perhaps in either the kernel config, or via CFLAGs, that removes some feature that is allowing this exploitable path in our chipsets? Pretty ugly stuff - and I wonder who has been exploiting this for years without the public knowing...

 

Kernel 4.14.11 has CONFIG_PAGE_TABLE_ISOLATION=y but that only for Meltdown attack. Spectre is a different beast

(edited)

----------

## CPUFan

Just FYI: This is "part" of a solution:

```
# Meltdown:

=sys-kernel/gentoo-sources-4.14.11-r2 ~amd64

```

 (followed by an update)

There will be 3 GLSAs about the full solution.

Thanks to grknight from #gentoo for confirming.Last edited by CPUFan on Thu Jan 04, 2018 8:01 pm; edited 1 time in total

----------

## eccerr0r

Anyone have the PoC code, and whether disabling L1/L2 caches would mitigate the problem?

Granted, this would kill performance really badly, but it's a stopgap solution? heh heh heh

----------

## Naib

 *NightMonkey wrote:*   

> Is there any mitigation possible, perhaps in either the kernel config, or via CFLAGs, that removes some feature that is allowing this exploitable path in our chipsets? Pretty ugly stuff - and I wonder who has been exploiting this for years without the public knowing...

 yes, buy a ryzen setup

----------

## Myu

@CPUFan : 

Have an Intel CPU and 4.14.11 ?  Then run

```
cat /proc/cpuinfo | grep -i insecure
```

If you have something like this, the KPTI patch is enabled :

```

bugs      : cpu_insecure

bugs      : cpu_insecure

...
```

----------

## ycUygB1

 *CPUFan wrote:*   

> 
> 
> There will be 3 GLSAs about the full solution.
> 
> Thanks to grknight from #gentoo for confirming.

 

Thank you.

----------

## Cyker

Wooo! Time for the C64 to RISE AGAIN!!!!!  :Laughing: 

----------

## EasterParade

[b]Last edited by EasterParade on Fri Jan 05, 2018 10:09 pm; edited 1 time in total

----------

## Joseph Powers

Can I patch the Meltdown bug with Gentoo hardened sources?

----------

## papas

great news for me 2 days ago I ordered a i7 8700k just to avoid the AMD segfault

----------

## 1clue

It's going to take awhile before any fixed hardware reaches the market. First the design needs to be fixed, then it needs to be tested and then boards need to be designed around the newer chips. We're all screwed for awhile.

----------

## Naib

 *1clue wrote:*   

> It's going to take awhile before any fixed hardware reaches the market. First the design needs to be fixed, then it needs to be tested and then boards need to be designed around the newer chips. We're all screwed for awhile.

 You can take the risk with present Ryzen stock & you might be lucky not to pick up with early fab issues OR wait a couple of months an Zen2 is due out 

If you want to stick with intel then sure... might take some time *if* they actually fix it (note they never actually fixed the fpu issue) as they have to gut their entire arch rather than building on it

----------

## 1clue

 *Naib wrote:*   

>  *1clue wrote:*   It's going to take awhile before any fixed hardware reaches the market. First the design needs to be fixed, then it needs to be tested and then boards need to be designed around the newer chips. We're all screwed for awhile. You can take the risk with present Ryzen stock & you might be lucky not to pick up with early fab issues OR wait a couple of months an Zen2 is due out 
> 
> If you want to stick with intel then sure... might take some time *if* they actually fix it (note they never actually fixed the fpu issue) as they have to gut their entire arch rather than building on it

 

FWIW I'm sticking with Intel.

The idea that they don't fix this is insane. The FPU issue was a minor irritant with an easy software fix. This decimates the security or speed of their entire processor line for the last 15 years.

----------

## gengreen

Better to directly turn off the javascript in about:config than use some plugins 

javascript is a general useflag, I will put it in my make.conf (-javascript)

it's better than nothing...

----------

## roki942

Came across these:

"We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare"  http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/

"Azure VMs borked following Meltdown patch, er, meltdown"  https://www.theregister.co.uk/2018/01/04/azure_vms_down_following_meltdown_patch/

----------

## luiztux

Who knows now is the chance of Open Source Hardware gaining momentum? Or live like Stallman ...   :Rolling Eyes: 

----------

## The Main Man

 *eccerr0r wrote:*   

> Anyone have the PoC code, and whether disabling L1/L2 caches would mitigate the problem?

 

PoC code :

http://cxsecurity.com/issue/WLB-2018010039

----------

## Naib

https://www.bleepingcomputer.com/news/security/mozilla-confirms-web-based-execution-vector-for-meltdown-and-spectre-attacks/

----------

## The Main Man

It's easier to copy the PoC code from here instead of the link I posted above:

https://github.com/Eugnis/spectre-attack

Anyway, I've executed this code on 4.14.11-gentoo-r2 with cpu_insecure and got this :

```
$ ./a.out                                                                                                                                                                          

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

zsh: illegal hardware instruction  ./a.out
```

Would be interesting to see the result on non-patched system but I can't do it atm.

----------

## gengreen

https://paste.pound-python.org/show/X9OyOjgzkEMCgOKMTwTc/

----------

## The Main Man

 *gengreen wrote:*   

> https://paste.pound-python.org/show/X9OyOjgzkEMCgOKMTwTc/

 

Interesting, so the code actually works. On patched or non-patched system?

I just had to try it and on the same machine I have another gentoo installation that hasn't been updated in awhile (couple of months) , and I get the same result (zsh: illegal hardware instruction  ./a.out), thought maybe it's zsh so I tried to execute in bash but I got the same thing. Maybe I'm doing something wrong, I've compiled the source with "gcc Source.c"

----------

## Naib

I just tried it on my patched BUT disabled system...

```

 ./a.out 

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

Reading at malicious_x = 0xffffffffffdfee18... Success: 0x54=’T’ score=2 

Reading at malicious_x = 0xffffffffffdfee19... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfee1a... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee1b... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee1c... Success: 0x4D=’M’ score=2 

Reading at malicious_x = 0xffffffffffdfee1d... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee1e... Success: 0x67=’g’ score=2 

Reading at malicious_x = 0xffffffffffdfee1f... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee20... Success: 0x63=’c’ score=2 

Reading at malicious_x = 0xffffffffffdfee21... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee22... Success: 0x57=’W’ score=2 

Reading at malicious_x = 0xffffffffffdfee23... Success: 0x6F=’o’ score=2 

Reading at malicious_x = 0xffffffffffdfee24... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee25... Success: 0x64=’d’ score=2 

Reading at malicious_x = 0xffffffffffdfee26... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee27... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee28... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee29... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee2a... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee2b... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee2c... Success: 0x53=’S’ score=2 

Reading at malicious_x = 0xffffffffffdfee2d... Success: 0x71=’q’ score=2 

Reading at malicious_x = 0xffffffffffdfee2e... Success: 0x75=’u’ score=2 

Reading at malicious_x = 0xffffffffffdfee2f... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee30... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee31... Success: 0x6D=’m’ score=2 

Reading at malicious_x = 0xffffffffffdfee32... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee33... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee34... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfee35... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee36... Success: 0x4F=’O’ score=2 

Reading at malicious_x = 0xffffffffffdfee37... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee38... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee39... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee3a... Success: 0x66=’f’ score=2 

Reading at malicious_x = 0xffffffffffdfee3b... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee3c... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee3d... Success: 0x67=’g’ score=2 

Reading at malicious_x = 0xffffffffffdfee3e... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee3f... Success: 0x2E=’.’ score=2 

```

This is a Ryzen setup and AMD states that this arch is susceptible to variant 1

----------

## gengreen

 *kajzer wrote:*   

>  *gengreen wrote:*   https://paste.pound-python.org/show/X9OyOjgzkEMCgOKMTwTc/ 
> 
> Interesting, so the code actually works. On patched or non-patched system?
> 
> I just had to try it and on the same machine I have another gentoo installation that hasn't been updated in awhile (couple of months) , and I get the same result (zsh: illegal hardware instruction  ./a.out), thought maybe it's zsh so I tried to execute in bash but I got the same thing. Maybe I'm doing something wrong, I've compiled the source with "gcc Source.c"

 

Unpatched

(I'm reinstall Gentoo from scratch with musl / minimal / hardened at this moment...)

----------

## The Main Man

Well, I just realized that there is only a patch for Meltdown , for Spectre there's no cure at the moment and this test is for Spectre.

It's all so confusing  :Smile: 

Still... I have to figure out why it's not working on my machine (which is good , I guess  :Smile:  )

----------

## gengreen

 *kajzer wrote:*   

> Well, I just realized that there is only a patch for Meltdown , for Spectre there's no cure at the moment and this test is for Spectre.
> 
> It's all so confusing 
> 
> Still... I have to figure out why it's not working on my machine (which is good , I guess  )

 

Indeed, cpu of your machine ?

----------

## The Main Man

 *gengreen wrote:*   

>  *kajzer wrote:*   Well, I just realized that there is only a patch for Meltdown , for Spectre there's no cure at the moment and this test is for Spectre.
> 
> It's all so confusing 
> 
> Still... I have to figure out why it's not working on my machine (which is good , I guess  ) 
> ...

 

Old dual core.

I'm on 17.1 profile and gcc 7.2.0, if that matters in this case.

Edit: actually that doesn't matter since on that other gentoo installation I don't have that, profile there is 13 and gcc is 5.4.0 I think.Last edited by The Main Man on Fri Jan 05, 2018 1:03 am; edited 1 time in total

----------

## gengreen

 *kajzer wrote:*   

>  *gengreen wrote:*    *kajzer wrote:*   Well, I just realized that there is only a patch for Meltdown , for Spectre there's no cure at the moment and this test is for Spectre.
> 
> It's all so confusing 
> 
> Still... I have to figure out why it's not working on my machine (which is good , I guess  ) 
> ...

 

can you show the output of a cat  *Quote:*   

> /proc/cpuinfo

  ?

How did you build Spectre.c ?

----------

## The Main Man

 *gengreen wrote:*   

> can you show the output of a cat /proc/cpuinfo?

 

```
$ cat /proc/cpuinfo                                                                                                                                                                                                       

processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 15

model name   : Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz

stepping   : 13

microcode   : 0xa4

cpu MHz      : 1200.000

cache size   : 1024 KB

physical id   : 0

siblings   : 2

core id      : 0

cpu cores   : 2

apicid      : 0

initial apicid   : 0

fpu      : yes

fpu_exception   : yes

cpuid level   : 10

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti dtherm

bugs      : cpu_insecure

bogomips   : 4784.78

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

processor   : 1

vendor_id   : GenuineIntel

cpu family   : 6

model      : 15

model name   : Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz

stepping   : 13

microcode   : 0xa4

cpu MHz      : 1200.000

cache size   : 1024 KB

physical id   : 0

siblings   : 2

core id      : 1

cpu cores   : 2

apicid      : 1

initial apicid   : 1

fpu      : yes

fpu_exception   : yes

cpuid level   : 10

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti dtherm

bugs      : cpu_insecure

bogomips   : 4784.78

clflush size   : 64

cache_alignment   : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

```

As I said before, I compiled the source with "gcc Source.c"

Now that I think of it I didn't compile on that other partition the source, just executed it, which might be the problem, I'll try it later.

Edit: I compiled it with gcc 6.4.0 and it was the same result, so I guess Spectre isn't working on old Intel CPUs, or maybe this PoC isn't, hard to tell.Last edited by The Main Man on Fri Jan 05, 2018 1:38 am; edited 1 time in total

----------

## eccerr0r

The PoC seems not to be clean for generic x86 as it uses clflush and rdtsc, so watch out for those older machines...

Also seems to be problems with my rdtsc on qemu KVM, so that bombs out.

Works scarily fine on 64-bit on an i7.

----------

## ct85711

Well, I complied it on my AMD A10-7850k (APU) system, and it appears to not be vulnerable to this issue.

Note:  I did not do anything special to compile it, beyond a straight gcc Source.c using gcc-7.2.0.

```
ct85711@Oate ~/tmp/spectre-attack $ ./a.out

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

Reading at malicious_x = 0xffffffffffdfedd8... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedd9... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedda... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfeddb... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfeddc... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfeddd... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedde... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfeddf... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede0... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede1... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede2... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede3... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede4... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede5... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede6... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede7... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede8... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfede9... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedea... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedeb... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedec... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfeded... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedee... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedef... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf0... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf1... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf2... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf3... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf4... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf5... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf6... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf7... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf8... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedf9... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedfa... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedfb... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedfc... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedfd... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedfe... Success: 0xFF=’?’ score=0

Reading at malicious_x = 0xffffffffffdfedff... Success: 0xFF=’?’ score=0

ct85711@Oate ~/tmp/spectre-attack $ cat /proc/cpuinfo

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 21

model           : 48

model name      : AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

stepping        : 1

microcode       : 0x6003104

cpu MHz         : 3700.000

cache size      : 2048 KB

...

```

----------

## nokilli

And I was all set to go all-in on Ethereum and its web3 stuff.  Dapps, if you weren't aware, are highly javascript-dependent and of course, are dealing with passphrases and private keys for which loss offers little hope of recovery.

There are some of us who were waiting to see what the powers-that-be response to crypto would be.  It is known that these same people have for long worked hard to subvert the security of our computer systems and for their own gain.  Now we see a very conveniently-timed reveal of just such a subversion.  Total market cap of crypto recently crossed $.75T USD.

----------

## Hu

 *greyspoke wrote:*   

> So if AMD and ARM are affected by spectre, does that mean it exposes a flaw in the instruction set they are implementing?  Or is there some shared code with a flaw in it?

 Neither.  The flaw is a design flaw in how the CPU optimizes evaluation of its native instruction set.  The ISA is fine in the abstract, which is why CPUs as different as IA32/x86_64/ARM can all have a problem.

 *yamabiko wrote:*   

> Is it possible to provide a patch for the current stable gentoo-sources? Manually patching it on 4.9.72 gives me an hunk fail.

 Maybe, but given the invasiveness of the changes, you really want the backport to be done by somebody who has been heavily involved in the Linux kernel memory management subsystem.  Some patches can be backported by anybody competent to read and write C.  In my opinion, these patches are not in that category, because they deal with very complicated and subtle logic in a core kernel component.  It's not enough to make the patches apply cleanly.  The backport maintainer also needs to know that any prerequisite changes have been backported, and those may have been included in 4.10/4.11/4.12/4.13 kernels by other people for other purposes, and thus not marked for backporting as part of this series.

 *1clue wrote:*   

>  *Ralphred wrote:*    *1clue wrote:*   It would be really neat if they fixed the bug with gcc 6.4 and recent kernels. The combination of this bug and the backported kernels is really unfortunate right now. 
> 
> I appreciate anecdotal evidence is mostly useless, but just built 4.14.11 with 6.4 and it's working fine, nothing funky other than the ~amd64 for the kernel in package.use I would be happy as a clam with that, except my attempt panics inside the first second of boot. No logs written.

 As a wild guess, since neither of you posted any details to confirm or refute this, Ralphred is on a non-hardened gcc and 1clue is on a hardened gcc.  As discussed in another thread, the solution (if this guess is accurate) is to use a non-hardened gcc, to include -fno-stack-check, or to upgrade to a kernel that includes -fno-stack-check automatically. *sligo wrote:*   

>  *Watcom wrote:*   So as you can see not running untrusted code goes a long way in preventing Spectre attacks. Does that include Javascript?

 Although the browsers attempt to sandbox Javascript, clever researchers keep identifying novel ways to do things that the Javascript sandbox really ought not allow, so I would say yes, it includes not running Javascript from untrusted hosts.

----------

## Ronaldlees

 *kajzer wrote:*   

> Well, I just realized that there is only a patch for Meltdown , for Spectre there's no cure at the moment and this test is for Spectre.
> 
> It's all so confusing 
> 
> Still... I have to figure out why it's not working on my machine (which is good , I guess  )

 

They're working on a (full?partial? - don't really know) "fix" for spectre:

https://support.google.com/faqs/answer/7625886

Basically it's a compiler re-do.

----------

## gengreen

A question remain and need some expert on this domain to give a proper answer since I haven't the sufficient knowledge in the low programming level  :

This is not first time that their hardware are compromised :

- https://www.techrepublic.com/article/is-the-intel-management-engine-a-backdoor/

- http://news.softpedia.com/news/intel-x86-cpus-come-with-a-secret-backdoor-that-nobody-can-touch-or-disable-505347.shtml

Intel is a very big corporate and have probably multi billion of dollars, I don't get how this kind of bug can be a mistake. They have an unlimited (almost) budget, skilled dev / worker to make a product of quality.

From intel

 *Quote:*   

> Is this a bug in Intel hardware or processor design?

 

 *Quote:*   

> No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms...

 

So they are saying that their product aren't responsable but it is because new exploits have just appear like some disease in certain country, a natural meteorology disaster or an experimental medicine... 

We are talking about technology , purely made by human from the scratch, so typically anything resulting from the tech cannot give some unexpected result, anything can be calculated, or known since we known how the thing work at 100 %. 

All this said, the question is 

Is this new flaw was purely a mistake or made by purpose ?Last edited by gengreen on Fri Jan 05, 2018 7:10 am; edited 1 time in total

----------

## eccerr0r

Should I be glad I haven't

emerge -e @world

on all my machines yet (after a new compiler is available)?  Sounds like this will be needed again to work around spectre?

----------

## nokilli

 *gengreen wrote:*   

> Is this new flaw was purely a mistake or made by purpose ?

 

We should probably move this line of inquiry over to Off the Wall.  Until then, look at the timing.  Did Intel move their design to another country at about the same time this flaw we introduced?  Has that country seen other incidents of misuse of American proprietary technology realized when corporations move their design work there?  Microsomething, I think, is a very notable example.  There is actually a long list of misdeeds along these lines but then too there is a taboo against discussing such things at work here that is very effective and which I don't believe many of you fully appreciate.

----------

## eccerr0r

They say that this was a problem ever since the ppro in 1994; I still have a ppro but unsure how to hack the code to test it as the PoC uses rdtsc and clflush which aren't supported by this old processor.  I suspect the problem still exists but harder to ensure the code actually "worked" versus side effect of a context swap or interrupt which could invalidate the slurped data.  (Anyone got this to work on a Core2, I can't seem to get rdtsc to work on my core2 machines.)

Incidentally, disabling rdtsc probably would make it harder to swipe data though it does NOT fix the problem as the problem still manifests without it.

Now the question I do have... Anyone with an Alpha and could test this, I'm curious...  They say that ia64 does not have this problem (VLIW...)

[Edit] It seems rdtsc should have been available since the Pentium; so perhaps need to figure out why it's showing up as an invalid instruction...

----------

## Aiken

 *eccerr0r wrote:*   

> (Anyone got this to work on a Core2, I can't seem to get rdtsc to work on my core2 machines.)
> 
> .
> 
> .
> ...

 

Do you mean rdtcs or rdtscp? C2d does have rdtsc but seems not to have rdtscp.

Awhile back I had something using __asm__ volatile ("rdtsc" : "=A" (x)); which works on c2d. If I change that to rdtscp I get Illegal Instruction. The spectre code works on my i7 7700k and i5 2500k. On both c2d and a celeron 550 both give illegal instruction on the rdtscp.

I have an 433MHz alpha that started life with nt4 but the big question, what safe place has it been put in.

edit: I changed the rdtscp to rdtsc. It runs but with the machine idle nothing found. Start running some 100% cpu processes and spectre starts finding characters but nothing like as accurate as the unmodified code on the i5 and i7. The c2d is a e8500 @ 3.16GHz.

----------

## PrSo

 *Naib wrote:*   

> I just tried it on my patched BUT disabled system...
> 
> ```
> 
>  ./a.out 
> ...

 

Same situation here, PTI disabled in kernel config, and with patch from amd disabling marking AMD cpu as insecure applied.

APU a6-6310

Did you try to execute this code after magical amd microcode 17h update?

----------

## krinn

Interresting, to read it you have to flush the cpu cache, but it's an sse2 instruction.

https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-reference-cacheability-support-intrinsics

So unability to use _mm_clflush doesn't protect from it, but avoid the cache flush and so avoid it.

on my affect core2 running x86 it couldn't flush its cache.

```
LC_ALL="C" ./a.out 

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

Instruction non permise

```

Look at that  :Smile: 

```
LANG="C" gcc  spectre.c -march=i686

In file included from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/xmmintrin.h:1249:0,

                 from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/x86intrin.h:31,

                 from spectre.c:8:

spectre.c: In function 'readMemoryByte':

/usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/emmintrin.h:1479:1: error: inlining failed in call to always_inline '_mm_clflush': target specific option mismatch

 _mm_clflush (void const *__A)

 ^

spectre.c:57:4: error: called from here

    _mm_clflush(&array2[i * 512]); /* intrinsic for clflush instruction */

    ^

In file included from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/xmmintrin.h:1249:0,

                 from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/x86intrin.h:31,

                 from spectre.c:8:

/usr/lib/gcc/i686-pc-linux-gnu/5.4.0/include/emmintrin.h:1479:1: error: inlining failed in call to always_inline '_mm_clflush': target specific option mismatch

 _mm_clflush (void const *__A)

 ^

spectre.c:63:4: error: called from here

    _mm_clflush(&array1_size);

```

```

LANG="C" gcc  spectre.c -march=core2 && echo "good"

good

```

Dunno if we have another way to flush cpu cache, but disabling sse2 for now, disallow _mm_clflush

2nd problem: how to disallow an sse2 ready cpu from using sse2 at runtime  :Smile: 

----------

## Watcom

You can flush (evict) the cache by reading from a large array. It's less convenient, but still possible. It's actually described in the paper.

----------

## krinn

I knew it wasn't that easy, else it would had been made already  :Smile: 

anyone also notice that pie made it worst?

when using the test program with -pie -fpie i get higher score (the program count backward, the higher the score, the fastest it has find the info), without pie i nearly always get a 2 score.

that's just for oddity, because as long as score is >0 you're doom.

(however i'm using pie with gcc 5.4, which might not be as good as 6.4)

----------

## Ant P.

 *roki942 wrote:*   

> Came across these:
> 
> "We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare"  http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/
> 
> "Azure VMs borked following Meltdown patch, er, meltdown"  https://www.theregister.co.uk/2018/01/04/azure_vms_down_following_meltdown_patch/

 

 *Quote:*   

> The preferred phrase at present is "coordinated disclosure." "Responsible disclosure" suggests the media and security researchers have been irresponsible for reporting on this issue before Intel was ready to go public. Once we get into assigning blame, that invites terms like "responsible microarchitecture design" or "responsible sales of processors known to contain vulnerabilities" or "responsible handling of security disclosures made last June."

 

 :Laughing: 

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 also worth noting - OBSD called out the state of Intel's garbage QA years before things like Poulsbo, xf86-video-intel becoming abandonware, all their network card bricking fiascos, defective BIOSes, Haswell TSX, hyperthreading data leaks, this, or next week's news.

----------

## JuNix

I have some interesting results for my Gentoo Xen HVM

I updated my system to 4.14.11-gentoo-r2 and the PoC code produces this

```
johnh@flatline ~ $ gcc Source.c -o plap

johnh@flatline ~ $ ./plap

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

Reading at malicious_x = 0xffffffffffdfee68... Success: 0x54=’T’ score=2 

Reading at malicious_x = 0xffffffffffdfee69... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfee6a... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee6b... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee6c... Success: 0x4D=’M’ score=2 

Reading at malicious_x = 0xffffffffffdfee6d... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee6e... Success: 0x67=’g’ score=2 

Reading at malicious_x = 0xffffffffffdfee6f... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee70... Success: 0x63=’c’ score=2 

Reading at malicious_x = 0xffffffffffdfee71... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee72... Success: 0x57=’W’ score=2 

Reading at malicious_x = 0xffffffffffdfee73... Success: 0x6F=’o’ score=2 

Reading at malicious_x = 0xffffffffffdfee74... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee75... Success: 0x64=’d’ score=2 

Reading at malicious_x = 0xffffffffffdfee76... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee77... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee78... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee79... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee7a... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee7b... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee7c... Success: 0x53=’S’ score=2 

Reading at malicious_x = 0xffffffffffdfee7d... Success: 0x71=’q’ score=2 

Reading at malicious_x = 0xffffffffffdfee7e... Success: 0x75=’u’ score=2 

Reading at malicious_x = 0xffffffffffdfee7f... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee80... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee81... Success: 0x6D=’m’ score=2 

Reading at malicious_x = 0xffffffffffdfee82... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee83... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee84... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfee85... Success: 0x20=’ ’ score=2 

Reading at malicious_x = 0xffffffffffdfee86... Success: 0x4F=’O’ score=2 

Reading at malicious_x = 0xffffffffffdfee87... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee88... Success: 0x73=’s’ score=2 

Reading at malicious_x = 0xffffffffffdfee89... Success: 0x69=’i’ score=2 

Reading at malicious_x = 0xffffffffffdfee8a... Success: 0x66=’f’ score=2 

Reading at malicious_x = 0xffffffffffdfee8b... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfee8c... Success: 0x61=’a’ score=2 

Reading at malicious_x = 0xffffffffffdfee8d... Success: 0x67=’g’ score=2 

Reading at malicious_x = 0xffffffffffdfee8e... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfee8f... Success: 0x2E=’.’ score=2 
```

which is an interesting result

```
johnh@flatline ~ $ dmesg|grep -i isola

[    0.000000] Kernel/User page tables isolation: enabled

johnh@flatline ~ $ grep ISOLA /usr/src/linux/.config

CONFIG_PAGE_TABLE_ISOLATION=y

johnh@flatline ~ $ uname -a

Linux flatline 4.14.11-gentoo-r2 #1 SMP PREEMPT Fri Jan 5 10:41:42 GMT 2018 x86_64 Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz GenuineIntel GNU/Linux

johnh@flatline ~ $ grep -i secure /proc/cpuinfo 

bugs      : cpu_insecure

bugs      : cpu_insecure
```

```
johnh@flatline ~ $ cat /proc/cpuinfo 

processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 60

model name   : Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz

stepping   : 3

microcode   : 0x1d

cpu MHz      : 2699.836

cache size   : 8192 KB

physical id   : 0

siblings   : 2

core id      : 0

cpu cores   : 2

apicid      : 0

initial apicid   : 0

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt

bugs      : cpu_insecure

bogomips   : 5399.98

clflush size   : 64

cache_alignment   : 64

address sizes   : 39 bits physical, 48 bits virtual

power management:

processor   : 1

vendor_id   : GenuineIntel

cpu family   : 6

model      : 60

model name   : Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz

stepping   : 3

microcode   : 0x1d

cpu MHz      : 2699.836

cache size   : 8192 KB

physical id   : 0

siblings   : 2

core id      : 1

cpu cores   : 2

apicid      : 2

initial apicid   : 2

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt

bugs      : cpu_insecure

bogomips   : 5399.98

clflush size   : 64

cache_alignment   : 64

address sizes   : 39 bits physical, 48 bits virtual

power management:
```

So, Xen hardware virtual machines need more than a local kernel fix, they need the actual Hypervisor code patched as well? Interesting......

----------

## yamabiko

 *JuNix wrote:*   

> I have some interesting results for my Gentoo Xen HVM
> 
> I updated my system to 4.14.11-gentoo-r2 and the PoC code produces this
> 
> So, Xen hardware virtual machines need more than a local kernel fix, they need the actual Hypervisor code patched as well? Interesting......

 

The patch is for Meltdown, not Spectre.

Is there a PoC that works on older processors?

Both https://github.com/Eugnis/spectre-attack/ and https://github.com/gkaindl/meltdown-poc (only for OSX ?) are not working on my core2.

----------

## Atom2

JuNix, *JuNix wrote:*   

> I have some interesting results for my Gentoo Xen HVM
> 
> I updated my system to 4.14.11-gentoo-r2 and the PoC code produces this
> 
> [snip]
> ...

 I don't think this proves anything with regards to XEN. My understanding is that HVM domUs (and 32 bit PV domUs) under XEN are not able to access data from (or in other words: data that exclusively belongs to) the hypervisor/dom0 or any other domU running under the hypervisor - and that's what XEN is and should be held accountable for.

In my view you can't hold XEN responsible for what is happening inside any domU guest. XEN just needs to make sure that nothing from one domU spills over to any other domU/the dom0 or that no single domU does have access to data from any other domU/the dom0.

Albeit XEN only provides a virtual machine environment for other systems to run inside which should be fully encapsulated from the hypervisor/dom0 and all other virtual machine environments running on the same hardware.

What's happening within any such XEN provided virtual machine environment is completely up to the operating system running therein. I would even go one step further and proclaim that XEN would be grossly wrong if it interfered with what's solely happening inside any of its domUs.

Regards Atom2

----------

## The Main Man

 *yamabiko wrote:*   

> Is there a PoC that works on older processors?
> 
> Both https://github.com/Eugnis/spectre-attack/ and https://github.com/gkaindl/meltdown-poc (only for OSX ?) are not working on my core2.

 

I asked the author and he promptly responded with the version that now works in my case.

What confuses me is that message isn't recovered and Spectre isn't patched AFAIK.

Check it here : 

https://github.com/Eugnis/spectre-attack/issues/6

----------

## krinn

because the new version is just buggy  :Smile: 

on my x86 core2: old version fail with the illegal instruction, and new version cannot leak anything

on my x86-64 corei7 : old version work, and new version cannot leak anything

```
./spectre-thread | grep malicious | head -1 && ./spectre-pie | grep malicious | head -1

Reading at malicious_x = 0xa0... Unclear: 0xF0=’?’ score=2500 (’?|?’ second: 0xC4=’?’ score=2500)

Reading at malicious_x = 0xffffffffffdfee78... Success: 0x54=’T’ score=2 

```

Last edited by krinn on Fri Jan 05, 2018 1:54 pm; edited 2 times in total

----------

## PrSo

I don't know how much it is relevant in this case, but reading papers about spectre in accordance of AMD vulnerability discovered that CONFIG_HAVE_EBPF_JIT is enabled in my kernel config.

The papers state that spectre 1 can be triggered in assumption that eBPF and JIT are enabled in config which should not be default, or maybe matters that the code is executed locally not remotely.

Did I misunderstood something?Last edited by PrSo on Fri Jan 05, 2018 2:04 pm; edited 1 time in total

----------

## yamabiko

 *kajzer wrote:*   

>  *yamabiko wrote:*   Is there a PoC that works on older processors?
> 
> Both https://github.com/Eugnis/spectre-attack/ and https://github.com/gkaindl/meltdown-poc (only for OSX ?) are not working on my core2. 
> 
> I asked the author and he promptly responded with the version that now works in my case.
> ...

 

Same result with an unpatched kernel.

----------

## rburcham

Some intrepid mod should sticky a summary in the top post.  There's a lot to know, and high risk for crosstalk and confusion.

Basic info/background/history:  https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

Chips from Intel, AMD and ARM are affected, with tested examples of each and statements from the manufacturers in the above link (except for Intel, whose statement it seems is not worth reading).

Both meltdown and spectre are variants of the same sort of attack, with meltdown targeting kernel memory and spectre targeting other in-process and external process memory that would otherwise be protected.

Meltdown can be defended against with >=sys-kernel/gentoo-sources-4.14.11-r2 and CONFIG_PAGE_TABLE_ISOLATION=y, which will be set automatically should you do a make olddefconfig against your previous .config.  This "fix" could result in a performance slowdown of your machine, maybe 5% - 30% depending on the type of workload, maybe nothing.

Spectre does not yet have a global fix available, and there is great activity across the app community https://en.wikipedia.org/wiki/Spectre%5f%28security%5fvulnerability%29#Mitigation, particularly in the web browser community https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/, to address the risk app by app.Last edited by rburcham on Fri Jan 05, 2018 2:15 pm; edited 2 times in total

----------

## mv

 *krinn wrote:*   

> anyone also notice that pie made it worst?

 

If the attacker can execute arbitrary code, he can choose pie or no-pie or whatever he wants.

 *Quote:*   

> without pie i nearly always get a 2 score.

 

I think that this is accident on your system. Here, pie doesn't influence the result; only sometimes (independent of pie) it needs longer. I suppose that it has more to do with scheduling/interrupt policy of the rest of your system. It might be that pie or non-pie is just by accident advantageous for a certain system.

----------

## The Main Man

 *krinn wrote:*   

> because the new version is just buggy 

 

Could be, he said to try changing threshold value, I tried with few values and I got some chars instead of '?' , but not the original message.

Maybe if I was to play the whole routine through some loop I would get the right one....

Anyhow, he also said that my cpu (Intel(R) Pentium(R) Dual CPU E2180) isn't in the affected list, which is interesting.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

----------

## krinn

 *kajzer wrote:*   

> Could be, he said to try changing threshold value

 

i didn't change it, but both use 80, i tried change -thread version to 120 with same result.

rather than be in the list or not, is your cpu running x86-64? because i'm sure my core2 is in it, but the non-thread doesn't work (with the same illegal instruction) and the -thread version run, but fail also on my x86-64 where the non-thread is able to leak info.

for now, the only thing you should conclude: it work on x86-64 for first version, the thread version do nothing.

mv: yeah right, he won't build it with -pie  :Smile: 

----------

## yamabiko

 *kajzer wrote:*   

> 
> 
> Anyhow, he also said that my cpu (Intel(R) Pentium(R) Dual CPU E2180) isn't in the affected list, which is interesting.
> 
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

 

Well, it seems that Penryn Core 2 processors aren't in the list too.

I've tried to change rdtscp to rdtsc, the code compiles but it shows '?' and/or random characters.

Regarding Meltdown, I also tried this https://github.com/corsix/meltdown-poc on an unpatched kernel and it runs on an i5 while it fails with "Illegal instruction" on the core2.

----------

## The Main Man

 *krinn wrote:*   

> 
> 
> rather than be in the list or not, is your cpu running x86-64? 
> 
> 

 

Yeah, it runs x86-64.

I mean aren't ALL core2 cpu's 64-bit?

Or maybe you mean that I for some reason run x86 OS.

----------

## krinn

 *kajzer wrote:*   

> I mean aren't ALL core2 cpu's 64-bit?
> 
> Or maybe you mean that I for some reason run x86 OS.

 

yes, i mean my core2 is running x86.

In case you wonder: model name	: Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz

----------

## krinn

ok... we're in deep trouble  :Smile: 

```
model name   : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

bugs      : cpu_insecure

uname -a

Linux beleg 4.14.11 #1 SMP PREEMPT Fri Jan 5 15:26:39 CET 2018 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux

dmesg | grep "iso\|Command line"

[    0.000000] Command line: root=/dev/sdb2 pti=on

[    0.000000] Kernel/User page tables isolation: enabled

./spectre

Putting 'The Magic Words are Squeamish Ossifrage.' in memory

Reading 40 bytes:

Reading at malicious_x = 0xffffffffffdfebe8... Success: 0x54=’T’ score=2 

Reading at malicious_x = 0xffffffffffdfebe9... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfebea... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfebeb... Success: 0x20=’ ’ score=2 

....

```

----------

## Atom2

Further information relating to XEN which just came through by E-Mail:

 *Quote:*   

> Hi all, this is a repost of https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have questions, please reply to this thread and we will try and improve the FAQ based on questions.
> 
> Regards
> 
> Lars
> ...

 

Furthermore, for XEN there is a practical response FAQ (which is WIP) available here: https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre

Regards Atom2

----------

## Naib

 *krinn wrote:*   

> ok... we're in deep trouble 
> 
> ```
> model name   : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
> 
> ...

 The PTI patch was only for Meltdown and intel only Back^M^M^Mug.  

You are executing a Spectre testcase, which to date has NOT been patched by anyone.  Spectre has always been the real concern & more of a concern for Intel than AMD

----------

## krinn

ah yes metldown so  :Smile: 

```
./meltdown 

poke buffer: 0x7ffa9ed5f000, page size: 4096

0x0000000000400fb0 | 48 6D 6D 2C 20 74 68 69  73 20 64 6F 65 73 20 72  |  Hmm, this does r 

0x0000000000400fc0 | 65 61 6C 6C 79 20 77 6F  72 6B 21                 |  eally work! 

```

----------

## Naib

have you tried this one? https://github.com/raphaelsc/Am-I-affected-by-Meltdown

looking over the code for a number of "meltdown" a large number are using the spectre code so people are confused there are three issues

----------

## krinn

 *Naib wrote:*   

> have you tried this one? https://github.com/raphaelsc/Am-I-affected-by-Meltdown
> 
> looking over the code for a number of "meltdown" a large number are using the spectre code so people are confused there are three issues

 

Thanks, it's meldown from upper link

I'll see if this one report the same problem with pti=on, and i could reboot to my previous kernel to see how it will react too.

edit: ah well, not really reliable, it miserably fail, even as root

```
# ./meltdown-checker 

Unable to find symbol sys_call_table in /proc/kallsyms

Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.14.11...

Failed to open /boot/System.map-4.14.11. Unable to proceed.

Abandon

```

ah lol ok

```

mount /boot

./meltdown-checker 

Unable to find symbol sys_call_table in /proc/kallsyms

Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.14.11...

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffff81a00120 ...

0x4343434301e71603 -> That's unknown

0x0303030303c75303 -> That's unknown

0xa3c3c3c3c3c30f18 -> That's unknown

0xa3a3a3a30f200f20 -> That's unknown

0x0707f3f3f3f3f30f -> That's unknown

0xb7b70f4367870f20 -> That's unknown

0x3337332720202707 -> That's unknown

0x20d3d3d3d3d3e320 -> That's unknown

0x1313130f0f070f0f -> That's unknown

0xa3a3570f570f5720 -> That's unknown

0x6767676720202020 -> That's unknown

0x2323030303030303 -> That's unknown

0x67676767670f2020 -> That's unknown

0x030303070f182020 -> That's unknown

0x0f2323232323201a -> That's unknown

0x6767c3c307070707 -> That's unknown

0x074303030303030f -> That's unknown

0x7373a3a3a320200f -> That's unknown

0x6767670f2020200f -> That's unknown

0xe7e7e7e7e7e70707 -> That's unknown

0xb7b7b7b70f20200f -> That's unknown

0x0f20f3f3f3f30f87 -> That's unknown

0xb7b7b7b7b7070707 -> That's unknown

0x2020232323232323 -> That's unknown

0xe387878787870f0f -> That's unknown

0x73737373200f2020 -> That's unknown

0x7373e3e3e3e32020 -> That's unknown

0xc7c7d3c70f20200f -> That's unknown

0x434320201a0f0f0f -> That's unknown

0x87878787870f200f -> That's unknown

0x200f0f200f0f0f20 -> That's unknown

0x732323232727180f -> That's unknown

0xd3d3d3d307070707 -> That's unknown

0x37370f1820015707 -> That's unknown

0xb7b72093930f0f0f -> That's unknown

0xb7b7b7e3e3e3e3e3 -> That's unknown

0x73c3474747470f20 -> That's unknown

0x20535753200f0f20 -> That's unknown

0xd3d3878787878720 -> That's unknown

0x3737333737202020 -> That's unknown

0x6767170f170f170f -> That's unknown

0xb7b7b7b7b7202018 -> That's unknown

0x030303a3a3a3a3a3 -> That's unknown

0x204747530f47200f -> That's unknown

0xe7e7e7e71820200f -> That's unknown

0x676703030303030f -> That's unknown

0xc3c3c3c3c3070707 -> That's unknown

0x1717172323230707 -> That's unknown

0xb720570f200f0f20 -> That's unknown

0xf3f3f3f320202020 -> That's unknown

System not affected. Congratulations!
```

I'll go try 4.4.78 (my previous kernel)

back with 4.4.78:

```
./meltdown-checker Unable to find symbol sys_call_table in /proc/kallsyms

Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.4.78...

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffff8142e120 ...

0x0723230700070707 -> That's unknown

0xffffffff8110c160 -> That's SyS_write

System affected! Please consider upgrading your kernel to one that is patched with KAISER

Check https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html for more details

```

So you're right naib, prevous link for meltdown is bad.

----------

## The Main Man

 *krinn wrote:*   

> 
> 
> yes, i mean my core2 is running x86.
> 
> 

 

Yeah, well it doesn't work in both cases then it seems.

Right now I'm not sure if that's because core2 isn't affected with spectre and meltdown or there's no PoC that works right with those old cpu's.

cat /proc/cpuinfo reports cpu_insecure bug though, hmm   :Rolling Eyes: 

----------

## krinn

 *kajzer wrote:*   

> cat /proc/cpuinfo reports cpu_insecure bug though, hmm  

 

Until proof a cpu is not affect, all X86 cpu are just mark insecure ; it doesn't mean yours is, just that it is default mark insecure.Last edited by krinn on Fri Jan 05, 2018 4:21 pm; edited 1 time in total

----------

## Naib

 *kajzer wrote:*   

>  *krinn wrote:*   
> 
> yes, i mean my core2 is running x86.
> 
>  
> ...

 

core2 definitely is affected. 

 *kajzer wrote:*   

> 
> 
> cat /proc/cpuinfo reports cpu_insecure bug though, hmm  

 That just means pti is enabled NOT that it has detected an insecure cpu

----------

## krinn

 *Naib wrote:*   

> That just means pti is enabled NOT that it has detected an insecure cpu

 

Not really, it doesn't mean pti is enable, just that the kernel has pti and the insecure status, and all x86 cpu are tag as insecure for now, amd has already sent a patch to get them out of the list http://lkml.iu.edu/hypermail/linux/kernel/1712.3/00675.html

There's no detection, just a white/black list of cpu

And having pti disable doesn't change it. (but having a cpu not tag insecure should indeed disable pti).

```
grep cpu_insecure /proc/cpuinfo && dmesg | grep "iso\|Command line" 

...

bugs      : cpu_insecure

[    0.000000] Command line: root=/dev/sdb2 pti=off

[    0.000000] Kernel/User page tables isolation: disabled on command line.

```

hard times for intel  :Smile: Last edited by krinn on Fri Jan 05, 2018 5:01 pm; edited 1 time in total

----------

## Naib

 *krinn wrote:*   

>  *Naib wrote:*   That just means pti is enabled NOT that it has detected an insecure cpu 
> 
> Not really, it doesn't mean pti is enable, just that the kernel has pti and the insecure status, and all x86 cpu are tag as insecure for now, amd has already sent a patch to get them out of the list http://lkml.iu.edu/hypermail/linux/kernel/1712.3/00675.html
> 
> There's no detection, just a white/black list of cpu
> ...

 

that what I said (－‸ლ)

The kernel doesn't do any form of detection, it is purely driven by the status of pti (on = mark insecure, off = don't mark). the rc6 has this for all x86 but rc7 (or final) will check for AMD CPU's as meltdown is intel-only.

----------

## krinn

 *Naib wrote:*   

> it is purely driven by the status of pti (on = mark insecure, off = don't mark).

 

i've edit to you shown you better pti doesn't do anything to the insecure status, but the insecure status should do something on pti.

----------

## Naib

You post is still wrong...

There is no whitelist of CPU's, the present RC has a blunt arch check.

```
+    /* Assume for now that ALL x86 CPUs are insecure */

+    setup_force_cpu_bug(X86_BUG_CPU_INSECURE
```

The original AMD patch and equally what is now in tip is a vendor check

```
+   if (c->x86_vendor != X86_VENDOR_AMD)

+        setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
```

A patched kernel has PTI capability and the check to make use of it is either enabled by default or controlled via the kernel cmdline. With PTI enabled the  page table isolation is enabled 

EQUALLY the /proc/cpuinfo bug flag is present, independent of pti status as this is controlled by hte code I posted. 

```
 uname -a && cat /proc/cmdline && grep -m 1 bug /proc/cpuinfo 

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=off

bugs      : sysret_ss_attrs null_seg cpu_insecure

```

Now this is rc6 so it is "enabled" for all x86 and as you can see with pti off, the cpu is still marked as the bug label and the mitigation are separate. I have not pulled tip to see how an AMD cpu is flagged but I suspect the check I posted then stops teh bugs being set

----------

## sligo

I've updated to the lasted kernel in portage on all my Intel driven systems. Is it of any use to update on my AMD box as well? Or does this only slow the CPU down without any benefit?

This is my CPU from AMD:

```
AMD Opteron 62xx class CPU
```

----------

## The Main Man

 *Naib wrote:*   

> core2 definitely is affected. 

 

I get that part now regarding "bugs: cpu_insecure", but based on what are you saying that core2 is definitely affected ?

I mean, now that Intel provided list of affected cpu's.

----------

## Naib

 *kajzer wrote:*   

>  *Naib wrote:*   core2 definitely is affected.  
> 
> I get that part now regarding "bugs: cpu_insecure", but based on what are you saying that core2 is definitely affected ?
> 
> I mean, now that Intel provided list of affected cpu's.

 

It will be affected by spectre as this is due to an oversight in a computer science concept to boost performance. 

Affected by Meltdown? If Intel have released a list to indicate what is affected and it isn't then maybe not BUT as an Intel CPU it will still be subject to the workaround

----------

## PrSo

 *sligo wrote:*   

> I've updated to the lasted kernel in portage on all my Intel driven systems. Is it of any use to update on my AMD box as well? Or does this only slow the CPU down without any benefit?
> 
> This is my CPU from AMD:
> 
> ```
> ...

 

Please, compile the: https://github.com/raphaelsc/Am-I-affected-by-Meltdown

My cpu - amd a6 6310

I am running kernel 4.14.11 with patches from AMD excluding theirs cpu from "insecure" list, and PTI off in kernel config, so that means "without meltdown patch applied".

After executing mentioned above PoC I have got:

```
./meltdown-checker

Your cpu doesn't support TSX (Transactional Synchronization Extensions)

Check https://software.intel.com/en-us/node/524022 for details;
```

IMHO that means what AMD sad about meltdown - it does not work on AMD cpu cause of differences in architecture.

----------

## The Main Man

 *Naib wrote:*   

> 
> 
> It will be affected by spectre as this is due to an oversight in a computer science concept to boost performance.
> 
> Affected by Meltdown? If Intel have released a list to indicate what is affected and it isn't then maybe not BUT as an Intel CPU it will still be subject to the workaround
> ...

 

Yeah, well it gets down to PoC, if it's so hard to write it for older cpu models, for both attacks, then maybe that speaks enough.

Meanwhile I found this :

Meltdown :

 *Quote:*   

> More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).

 

Spectre :

 *Quote:*   

> Spectre, on the other hand, appears to have a much wider reach. According to researchers, nearly every type of device is affected by Spectre; it has been verified to work across Intel, AMD, and ARM processors. Spectre is harder to exploit than Meltdown, but researchers caution that it is also harder to guard against.

 

https://www.windowscentral.com/all-modern-processors-impacted-new-meltdown-and-spectre-exploits

----------

## Aiken

With spectre I get better results with the original test on core2 with rdtscp changed to rdtsc. Run a couple of cpu intensive processes and the original over many runs starts recovering the message. With the new version all I get are either ? or gibberish.

----------

## krinn

Stop playing words...

 *Naib wrote:*   

> There is no whitelist of CPU's, the present RC has a blunt arch check.
> 
> ```
> +    /* Assume for now that ALL x86 CPUs are insecure */
> 
> ...

 

A blacklist

 *Quote:*   

> 
> 
> ```
> +   if (c->x86_vendor != X86_VENDOR_AMD)
> 
> ...

 

A whitelist

So i could agree they are not white and black list, but i cannot think you mistake that is was shortcut that do resume pretty well how it is handle.

I'm not in mood to shown the code each time we speak about it, and white/black list resume it pretty well.

 *Naib wrote:*   

> A patched kernel has PTI capability and the check to make use of it is either enabled by default or controlled via the kernel cmdline. With PTI enabled the  page table isolation is enabled

 

No: a PTI ready kernel is default set to "auto" ; a 3 states that could be alter from cmdline as-well, with

"auto" PTI enable if cpu has X86_BUG_CPU_INSECURE, disable if cpu doesn't have it ; that's why amd just push their cpu in the whitelist, it's enough to disable PTI.

"no" disable

"yes" enable

 *Naib wrote:*   

> EQUALLY the /proc/cpuinfo bug flag is present, independent of pti status as this is controlled by hte code I posted. 

 

Agree, but that's not what you said earlier and why i have object.

See

 *Naib wrote:*   

>  *kajzer wrote:*   cat /proc/cpuinfo reports cpu_insecure bug though, hmm   
> 
> That just means pti is enabled NOT that it has detected an insecure cpu

 

And again here:

 *Naib wrote:*   

> it is purely driven by the status of pti (on = mark insecure, off = don't mark).

 

No, pti on or off will not mark insecure as this is driven by the white/black list (yeah i love them as black/white list)

I have no problem to say when i'm wrong, but i wasn't ; while you were, more than once.

----------

## sligo

 *PrSo wrote:*   

>  *sligo wrote:*   I've updated to the lasted kernel in portage on all my Intel driven systems. Is it of any use to update on my AMD box as well? Or does this only slow the CPU down without any benefit?
> 
> This is my CPU from AMD:
> 
> ```
> ...

 

I've just tried that on that unpatched AMD server and a Intel system with patched kernel. On both, i got the same output:

```
Your cpu doesn't support TSX (Transactional Synchronization Extensions)
```

Looking at the issues on Github, it seems like that this tool is not yet finished and people getting this kind of message on multiple affected Intel CPUs. For now i'll better wait for the patches on that Meltdown Checker tool.

----------

## yamabiko

 *Aiken wrote:*   

> With spectre I get better results with the original test on core2 with rdtscp changed to rdtsc. Run a couple of cpu intensive processes and the original over many runs starts recovering the message. With the new version all I get are either ? or gibberish.

 

Which CPU exactly?

----------

## Chiitoo

Did no one else have issues with 4.14.11 && CONFIG_PAGE_TABLE_ISOLATION=y && AMD?

For me, running Steam would lock up the (AMD Ryzen) machine.  Hard.

The patch here helped me over it: https://lkml.org/lkml/2018/1/3/563

```
arch/x86/entry/entry_64_compat.S |   13 ++++++-------

 1 file changed, 6 insertions(+), 7 deletions(-)

--- a/arch/x86/entry/entry_64_compat.S

+++ b/arch/x86/entry/entry_64_compat.S

@@ -190,8 +190,13 @@ ENTRY(entry_SYSCALL_compat)

    /* Interrupts are off on entry. */

    swapgs

 

-   /* Stash user ESP and switch to the kernel stack. */

+   /* Stash user ESP */

    movl   %esp, %r8d

+

+   /* Use %rsp as scratch reg. User ESP is stashed in r8 */

+   SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp

+   

+   /* Switch to the kernel stack */

    movq   PER_CPU_VAR(cpu_current_top_of_stack), %rsp

 

    /* Construct struct pt_regs on stack */

@@ -220,12 +225,6 @@ GLOBAL(entry_SYSCALL_compat_after_hwfram

    pushq   $0         /* pt_regs->r15 = 0 */

 

    /*

-    * We just saved %rdi so it is safe to clobber.  It is not

-    * preserved during the C calls inside TRACE_IRQS_OFF anyway.

-    */

-   SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi

-

-   /*

     * User mode is traced as though IRQs are on, and SYSENTER

     * turned them off.

     */
```

----------

## Aiken

 *yamabiko wrote:*   

>  *Aiken wrote:*   With spectre I get better results with the original test on core2 with rdtscp changed to rdtsc. Run a couple of cpu intensive processes and the original over many runs starts recovering the message. With the new version all I get are either ? or gibberish. 
> 
> Which CPU exactly?

 

The same cpu I mentioned on page 4 where I originally tried rdtsc instead of rdtscp, a core2 e8500 @ 3.16GHz.

----------

## PrSo

 *sligo wrote:*   

> 
> 
> Looking at the issues on Github, it seems like that this tool is not yet finished and people getting this kind of message on multiple affected Intel CPUs. For now i'll better wait for the patches on that Meltdown Checker tool.

 

DUNNO about that. My Intel rig was explicitly compromised without PTI patch. Agree that we have to wait for TSX support.

My apologies.

----------

## yamabiko

 *Aiken wrote:*   

>  *yamabiko wrote:*    *Aiken wrote:*   With spectre I get better results with the original test on core2 with rdtscp changed to rdtsc. Run a couple of cpu intensive processes and the original over many runs starts recovering the message. With the new version all I get are either ? or gibberish. 
> 
> Which CPU exactly? 
> 
> The same cpu I mentioned on page 4 where I originally tried rdtsc instead of rdtscp, a core2 e8500 @ 3.16GHz.

 

okay, I can get some characters when putting the CPU on very heavy load (compiling + some HD video on mpv):

Reading at malicious_x = 0xffffffffffdfeee8... Success: 0x54=’T’ score=2 

Reading at malicious_x = 0xffffffffffdfeee9... Success: 0x68=’h’ score=2 

Reading at malicious_x = 0xffffffffffdfeeea... Unclear: 0x02=’?’ score=54 (second best: 0x0A score=53)

Reading at malicious_x = 0xffffffffffdfeeeb... Unclear: 0x07=’?’ score=55 (second best: 0x08 score=53)

Reading at malicious_x = 0xffffffffffdfeeec... Unclear: 0x0A=’?’ score=55 (second best: 0x02 score=55)

Reading at malicious_x = 0xffffffffffdfeeed... Unclear: 0x0E=’?’ score=59 (second best: 0x00 score=55)

Reading at malicious_x = 0xffffffffffdfeeee... Unclear: 0x06=’?’ score=59 (second best: 0x07 score=56)

Reading at malicious_x = 0xffffffffffdfeeef... Unclear: 0x00=’?’ score=55 (second best: 0x0A score=52)

Reading at malicious_x = 0xffffffffffdfeef0... Success: 0x63=’c’ score=2 

Reading at malicious_x = 0xffffffffffdfeef1... Unclear: 0x0E=’?’ score=55 (second best: 0x00 score=52)

Reading at malicious_x = 0xffffffffffdfeef2... Unclear: 0x0A=’?’ score=53 (second best: 0x0E score=52)

Reading at malicious_x = 0xffffffffffdfeef3... Unclear: 0x00=’?’ score=59 (second best: 0x0E score=54)

Reading at malicious_x = 0xffffffffffdfeef4... Unclear: 0x01=’?’ score=55 (second best: 0x07 score=54)

Reading at malicious_x = 0xffffffffffdfeef5... Unclear: 0x64=’d’ score=69 (second best: 0x09 score=56)

Reading at malicious_x = 0xffffffffffdfeef6... Unclear: 0x02=’?’ score=55 (second best: 0x00 score=54)

Reading at malicious_x = 0xffffffffffdfeef7... Unclear: 0x0E=’?’ score=56 (second best: 0x20 score=53)

Reading at malicious_x = 0xffffffffffdfeef8... Unclear: 0x61=’a’ score=58 (second best: 0x01 score=54)

Reading at malicious_x = 0xffffffffffdfeef9... Success: 0x72=’r’ score=2 

Reading at malicious_x = 0xffffffffffdfeefa... Success: 0x65=’e’ score=2 

Reading at malicious_x = 0xffffffffffdfeefb... Unclear: 0x20=’ ’ score=64 (second best: 0x06 score=54)

Reading at malicious_x = 0xffffffffffdfeefc... Unclear: 0x53=’S’ score=58 (second best: 0x09 score=54)

Reading at malicious_x = 0xffffffffffdfeefd... Success: 0x71=’q’ score=2 

Reading at malicious_x = 0xffffffffffdfeefe... Success: 0x75=’u’ score=2 

Reading at malicious_x = 0xffffffffffdfeeff... Unclear: 0x0A=’?’ score=55 (second best: 0x02 score=54)

Reading at malicious_x = 0xffffffffffdfef00... Unclear: 0x0E=’?’ score=55 (second best: 0x02 score=54)

Reading at malicious_x = 0xffffffffffdfef01... Unclear: 0x02=’?’ score=55 (second best: 0x01 score=53)

Reading at malicious_x = 0xffffffffffdfef02... Unclear: 0x0E=’?’ score=54 (second best: 0x08 score=54)

Reading at malicious_x = 0xffffffffffdfef03... Unclear: 0x08=’?’ score=55 (second best: 0x01 score=53)

Reading at malicious_x = 0xffffffffffdfef04... Unclear: 0x06=’?’ score=51 (second best: 0x07 score=50)

Reading at malicious_x = 0xffffffffffdfef05... Unclear: 0x08=’?’ score=54 (second best: 0x07 score=53)

Reading at malicious_x = 0xffffffffffdfef06... Success: 0x4F=’O’ score=2 

Reading at malicious_x = 0xffffffffffdfef07... Unclear: 0x08=’?’ score=57 (second best: 0x02 score=55)

Reading at malicious_x = 0xffffffffffdfef08... Unclear: 0x73=’s’ score=54 (second best: 0x0E score=54)

Reading at malicious_x = 0xffffffffffdfef09... Unclear: 0x69=’i’ score=55 (second best: 0x06 score=54)

Reading at malicious_x = 0xffffffffffdfef0a... Unclear: 0x01=’?’ score=54 (second best: 0x02 score=53)

Reading at malicious_x = 0xffffffffffdfef0b... Unclear: 0x72=’r’ score=56 (second best: 0x07 score=52)

Reading at malicious_x = 0xffffffffffdfef0c... Unclear: 0x06=’?’ score=62 (second best: 0x07 score=57)

Reading at malicious_x = 0xffffffffffdfef0d... Unclear: 0x0A=’?’ score=54 (second best: 0x09 score=51)

Reading at malicious_x = 0xffffffffffdfef0e... Unclear: 0x02=’?’ score=56 (second best: 0x01 score=56)

Reading at malicious_x = 0xffffffffffdfef0f... Unclear: 0x2E=’.’ score=56 (second best: 0x00 score=54)

----------

## Aiken

I get different characters with different runs. The impression I was getting with enough runs a person could still get the message. Just no where near as quickly as I was seeing my i5 and i7. Was getting better results playing with cpu load than I was with the threshold.

----------

## eccerr0r

Any predictions what will be the stable gentoo-sources that will contain the PTI change?

----------

## Spargeltarzan

What exatly will be the role of the new microcode intel-microcode-20171117_p20171215? I thought with microcode loading it is not fixable?

----------

## eccerr0r

It disables a feature that is necessary by spectre.

----------

## PrSo

 *Spargeltarzan wrote:*   

> What exatly will be the role of the new microcode intel-microcode-20171117_p20171215? I thought with microcode loading it is not fixable?

 

Devs are working on spectre vulnerability where microcode plays its role:

https://lkml.org/lkml/2018/1/4/615

and this is a "retpoline" WIP:

https://lkml.org/lkml/2018/1/3/780

----------

## Pearlseattle

Hi

Which versions of "gentoo-sources" have gotten the patches against the "Meltdown"-attack?

I did see here https://packages.gentoo.org/packages/sys-kernel/gentoo-sources that some versions were masked by Alice, but I tend to think that the Meltdown-fix hasn't been integrated in all versions that aren't hard-masked... (it would anyway require a new release to be published for the affected version, right?) .

How can I find out which versions got the fix against "Meltdown"?

Thx   :Smile: 

Edit 6.Jan.2018 01:00 CET

Expanding:

A) I understood that the now famous KPTI (Kernel Page Table Isolation) feature protects against "Meltdown"-attacks (performance impact to be assessed depending on application's activity).

B) I understood that the KPTI-feature is activated through the "CONFIG_PAGE_TABLE_ISOLATION" parameter.

If I do e.g. against my current kernel...

```
grep -ir page_table_isolation /usr/src/linux-4.9.6-gentoo-r1/ 2>/dev/null
```

...I find nothing, and if I do the same against the latest stable kernel...

```
grep -ir page_table_isolation /usr/src/linux-4.9.72-gentoo/ 2>/dev/null
```

...I find again nothing, but if I unmask and install the latest kernel (4.14.12) I do get hits:

```
grep -ir page_table_isolation /usr/src/linux-4.14.12-gentoo/ 2>/dev/null

/usr/src/linux-4.14.12-gentoo/security/Kconfig:config PAGE_TABLE_ISOLATION

/usr/src/linux-4.14.12-gentoo/include/linux/pti.h:#ifdef CONFIG_PAGE_TABLE_ISOLATION

/usr/src/linux-4.14.12-gentoo/arch/x86/mm/dump_pagetables.c:#ifdef CONFIG_PAGE_TABLE_ISOLATION

...etc...

```

Therefore, I do now know that 4.14.12 has the patch, but what I really miss is something that lists ALL the kernels that got the patch/workaround for at least "Meltdown (which therefore have the entry "PAGE_TABLE_ISOLATION")".

Reason: I've got multiple hosts that have different kernel dependencies (modules or SW) => some do not yet work with the 4.14-series => I need to be able to identify which (old) kernels are OK to then be able to assess pros/cons vs. dependencies => I would love not to have to download all previous kernels to then assess their availability of KPTI   :Very Happy:  .

Cheers!   :Smile: 

Edit 6.Jan.2018 02:20 CET

Dropped email to "Alice" (Gentoo kernel maintainer).

----------

## Aiken

 *yamabiko wrote:*   

> 
> 
> okay, I can get some characters when putting the CPU on very heavy load (compiling + some HD video on mpv):
> 
> 

 

Changed it so the recovered characters are displayed as a string. Merging the result of 20 runs on my core2 I get The M?gic Words ?re Squeam?sh Ossifr?ge.

Not sure how valid this is in general but at least with this test could eventually get the whole string.

```

recovered string ????????????????????S??????sh???si????e?

recovered string ??????????????? ??? ??????????O???fr???.

recovered string ??e M?gic Wor???????????????? ??????????

recovered string ????M????????????????q?????s? O???fr????

recovered string T?e?M?g????o??????e???u???????Oss?fr??e?

recovered string ??? ????? ?????????????????s?????????g??

recovered string ?h??M???? ???????re???u?????????????????

recovered string ?h??M?g??????????r??????????h?????????e?

recovered string ??e?M?g?? ??????????????????????s??r??e?

recovered string T?e???g???Wo???????????????s???????????.

recovered string ?h??????? ?o?d????e???uea???????????????

recovered string T?e?????? ??rd? ?????????m?s? ??s????g?.

recovered string ??e?????? ??r?????? ?????m?????s?????g??

recovered string T?? ??????????????? S??????????????????.

recovered string ??? M???c????????????????m??h?O????r????

recovered string ???????????o??????? ??u?????????????????

recovered string ?h? ????c ??????????????????????????????

recovered string ????????c ?o????????????????????????????

recovered string ??????g?? ??????????????????????????????

recovered string ??e ??????????s??re S????m??? Oss?f??ge.

```

----------

## eccerr0r

That proves it can be recovered but will take longer to get the data.  What hacks did you do so it can run on core2? (remove clflush, rdtsct to rdtsc?)

----------

## Hu

 *gengreen wrote:*   

> A question remain and need some expert on this domain to give a proper answer since I haven't the sufficient knowledge in the low programming level  :
> 
> Intel is a very big corporate and have probably multi billion of dollars, I don't get how this kind of bug can be a mistake. They have an unlimited (almost) budget, skilled dev / worker to make a product of quality.

 Security is hard, especially if you don't think about it.  This looks to me like the relevant designers assumed that information was only exposed through supported channels, so by canceling the register updates when the exception occurs, there would be no problem.  If the cache timing side channel attack did not exist, that assumption could be right.  Since the cache timing attack exists, the assumption is wrong.  It's not at all surprising that Intel is spinning this as "by design", "not an issue", etc.  Given the projected number of affected CPUs, the inability to fix it in software without variable but potentially serious side effects (the performance costs of KPTI), and the notable expense of purchasing replacement hardware (ignoring that there is no acceptable replacement at the moment), admitting it is a design flaw could easily lead to massive public pressure for a recall.  Even with Intel's considerable resources, that large a recall would be extremely painful.  They understandably want to avoid even discussing a recall, and insisting that this is "by design" is a necessary part of that avoidance.

 *PrSo wrote:*   

> I don't know how much it is relevant in this case, but reading papers about spectre in accordance of AMD vulnerability discovered that CONFIG_HAVE_EBPF_JIT is enabled in my kernel config.
> 
> Did I misunderstood something?

 In general, CONFIG_HAVE_ symbols are forced on as a function of your architecture and indicate only that the kernel on your architecture can be built with that feature.  It does not mean you enabled the feature.  A separate symbol controls enabling it.

----------

## Aiken

 *eccerr0r wrote:*   

> That proves it can be recovered but will take longer to get the data.  What hacks did you do so it can run on core2? (remove clflush, rdtsct to rdtsc?)

 

Replaced both references to __rdtscp(&junk) with __rdtsc() and while I got the above results on the core2 not giving me anything meaningful on my i5 or i7 while the original rdtscp code works on them.

```

--- Source.c   2018-01-06 10:03:16.002147757 +1000

+++ Source-rdtsc.c   2018-01-06 10:01:20.758716899 +1000

@@ -80,9 +80,9 @@

       {

          mix_i = ((i * 167) + 13) & 255;

          addr = &array2[mix_i * 512];

-         time1 = __rdtscp(&junk); /* READ TIMER */

+         time1 = __rdtsc(); /* READ TIMER */

          junk = *addr; /* MEMORY ACCESS TO TIME */

-         time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

+         time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

          if (time2 <= CACHE_HIT_THRESHOLD && mix_i != array1[tries % array1_size])

             results[mix_i]++; /* cache hit - add +1 to score for this value */

```

----------

## eccerr0r

Hmm.  Using rdtsc now allows the spectre test to work on my core2 (core2quad) - and similarly though it has a fairly low success rate, it just means it will take longer to recover the whole string, nevertheless it will eventually get it.  Boo.  The x86 VM running upon that machine is a little more successful than the bare iron.

I don't have any newer AMD machines but curious on my AthlonXP(Thoroughbred and Barton) and Athlon64 (original)...

Patch time...

----------

## Aiken

Just did the same on a machine cpuid is saying Intel Pentium 4 (Prescott R0), 90nm. Got nowhere with rdtsc and ended up replacing the rdtsc calls with int clock_gettime(clockid_t clk_id, struct timespec *tp); where clk_id is CLOCK_REALTIME then tweaking the threshold.

After 20 runs got The Magic Words are SqKeamish Ossifrage.

----------

## miket

This was a thing I noticed yesterday.  The KPTI (Kernel Page-Table Isolation) patch made it into the in-development 4.15 kernel in November.  Using an in-development kernel is truly living on the edge:  it is inadvisable to use one for an in-production system.

As I saw yesterday, the KPTI patch has been backported to the 4.14 and 4.9-series kernels:  versions 4.14.11 and 4.9.74.  By now a second round of patches have been applied, one of which disables the KPTI patch when the kernel runs on an AMD processor because Meltdown has not been observed on AMD processors.

So if you're looking for kernels that have the KPTI patch, look for version >= 4.14.11 for the 4.14 series or >= 4.9.74 for the 4.9 series.  The patch also exists in 4.4.109 and above.  It looks like there are no patches for older long-term series (4.1, 3.18, 3.16, 3.2).

One other thing of note.  The KPTI patch is projected to incur a performance hit because it requires extra instructions for switching sets of page-map tables at every switch between user and kernel mode--in both directions.  Reportedly, the PCID feature that has been present in Intel processors for a number of years would, if the operating system were set up to use it, greatly lessen this impact on performance.  From what I've read, the 4.14 series kernels do include the special PCID handling.  The upshot is that the 4.14.11+ kernels would likely perform better than the 4.9.74+ kernels.

To find if your processor has the PCID feature is pretty simple:

```
grep ' pcid ' /proc/cpuinfo
```

  If you see any output when you run this, your processor has the feature.

----------

## PrSo

 *sligo wrote:*   

> 
> 
> Looking at the issues on Github, it seems like that this tool is not yet finished and people getting this kind of message on multiple affected Intel CPUs. For now i'll better wait for the patches on that Meltdown Checker tool.

 

The code has been already updated against TSX support.

On my AMD rig I have:

```
Unable to find symbol sys_call_table in /proc/kallsyms

Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.14.11-gentoo...

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffff81e00120 ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

System not affected. Congratulations!

```

so as AMD sad, my cpu isnt affected by meltdown.

@Hu

Thanks for clarifying that it is default option on my cpu architecture.

Checking config file for BPF produces:

```
cat /boot/config-4.14.11-gentoo | grep BPF

CONFIG_BPF=y

# CONFIG_BPF_SYSCALL is not set

# CONFIG_NET_CLS_BPF is not set

# CONFIG_NET_ACT_BPF is not set

# CONFIG_BPF_JIT is not set

CONFIG_HAVE_EBPF_JIT=y

# CONFIG_TEST_BPF is not set
```

Maybe "non standard" settings means CONFIG_BPF_JIT and CONFIG_BPF_SYSCALL are enabled.

----------

## gengreen

Any patch available against meltdown for the branch 4.9.x ? I could not make the KAISER patch work...

Thank you HU for your precision about my question btw

----------

## fedeliallalinea

 *gengreen wrote:*   

> Any patch available against meltdown for the branch 4.9.x ? I could not make the KAISER patch work...

 

kernel 4.9.75 should be backport KPTI patch

 *https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.75 wrote:*   

> commit ea6cd39d230f71e27facc0667c1986504e5b0f54
> 
> Author: Kees Cook <keescook@chromium.org>
> 
> Date:   Wed Jan 3 10:18:01 2018 -0800
> ...

 

----------

## The Main Man

Meltdown checker works fine now with core2 

```
./meltdown-checker                                                                                                                                                                                                         

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffffa3a00180 ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

System not affected. Congratulations!

```

Edit: Just tested this on unpatched system :

```
./meltdown-checker                                                                                                                                                                                                    

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffffa36001c0 ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

0xffffffffa2e22980 -> That's SyS_mmap

System affected! Please consider upgrading your kernel to one that is patched with KAISER

Check https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html for more details
```

----------

## krinn

if you want find your kernel is running KPTI

```
dmesg | grep iso

[    0.000000] Kernel/User page tables isolation: enabled
```

And to answer your question: i think no gentoo-sources will have any patches against "Meltdown" attack, gentoo-sources without KPTI will be certainly mask and put out of the tree, and no patches will be use, but only KPTI kernels.

It wouldn't really make sense to patch end of life kernels to use KPTI, because KPTI certainly isn't something tiny to add to a kernel (lot of changes for sure).

So the more reasonable thing to do is kick off kernels without KPTI, and stabilize any kernel with it you may think is "good enough" to get stable.

stabilization rules is always crush when security is in the game ; you can wait x times to stabilize or wait for a version that has less open bugs to stabilize ; but when security mean "updating" ; all rules are off, and you stabilize anything that even work on one feet, solely base on "it have the needed security update".

----------

## t3k0

I installed the microcode update as described  in the gentoo wiki. However, since I own an Intel core i5 with Sandy Bridge architecture, I believe this is pretty useless?

After updating I get:

```

dmesg | grep microcode

[    0.000000] microcode: microcode updated early to revision 0x29, date = 2013-06-12

[    0.520508] microcode: sig=0x206a7, pf=0x2, revision=0x29

[    0.522882] microcode: Microcode Update Driver: v2.2.

```

Does anybody know if there will be an update for older architectures than Haswell, Skylake, or Broadwell or won't an update for older processors be delivered?

----------

## gengreen

```
sys-firmware/intel-microcode 20171117_p20171215
```

Processor Skylake

```

vendor_id   : GenuineIntel

cpu family   : 6

model      : 94

model name   : Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz

```

```
dmesg |grep microcode

[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09

[    2.691311] microcode: sig=0x506e3, pf=0x20, revision=0xba

[    2.691416] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
```

Doesn't work...

```
meltdown-poc $ ./a.out 

poke buffer: 0x385411eb000, page size: 4096

0x000000497ab0e180 | 48 6D 6D 2C 20 74 68 69  73 20 64 6F 65 73 20 72  |  Hmm, this does r 

0x000000497ab0e190 | 65 61 6C 6C 79 20 77 6F  72 6B 21                 |  eally work!
```

 *Quote:*   

> 
> 
> kernel 4.9.75 should be backport KPTI patch 

 

Good news, thanksLast edited by gengreen on Sat Jan 06, 2018 9:00 pm; edited 2 times in total

----------

## wrc1944

@Tony0945,

I looked in make xconfig. and found this in the "Search Config" dialog box:

The option in config is called "Remove the kernel mapping in user mode", and is checked "y" so as to "enable."

 *Quote:*   

> Remove the kernel mapping in user mode (PAGE_TABLE_ISOLATION)
> 
> CONFIG_PAGE_TABLE_ISOLATION:
> 
> This feature reduces the number of hardware side channels by
> ...

 

I'm confused as to what you wrote in your post on Page 1, where you said:  *Quote:*   

> Watch out when updating your kernel if you have an AMD chip. Once you enable PAGE_TABLE_ISOLATION via make oldconfig you can;t turn it off with make menuconfig.
> 
> I wondered why my Athlon II was suddenly really slow launching X. I had to reboout with 4.14-10-r1 and update it again to 4.14.11 to choose "n" instead of "y" in make oldconfig.
> 
> Unless someone knows that this is needed for AMD too. Other sources on the web say this is for Intel only not AMD. But I'd like to hear it from our kernel experts. 

 

In my 4.14.11-gentoo config, it's set CONFIG_PAGE_TABLE_ISOLATION=y (apparently by default), which I take to mean saying "y" removes and does NOT enable for kernel mapping in user mode. So, if you choose "n" for this option, one would NOT be removing kernel mapping in user mode, but in reality be enabling it. 

Maybe I'm just missing something?  I guess a better way to understand this is to just ask if we have an amd cpu, do we currently want this option to be checked "y", or "n"?

I'm currently doing 4.11.12-gentoo, and guess I'll for now leave it checked "y" as I didn't notice any performance hit on my 4.14.11-gentoo where default was "y", which I had installed before I read much on this. I too would appreciate an expert elightenment on this, "y,"  or "n," and maybe a little "why" as to either.

----------

## Zucca

I'm little late to the "party", but where can I obtain that meltdown-checker?

----------

## Fitzcarraldo

 *Zucca wrote:*   

> I'm little late to the "party", but where can I obtain that meltdown-checker?

 

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

----------

## PrSo

Here is a patch for spectre v1 WIP:

https://lkml.org/lkml/2018/1/5/769

https://lkml.org/lkml/2018/1/5/383

It's worth to mention that for AMD change of microcode probably wont be needed:

https://lkml.org/lkml/2018/1/5/383

https://lkml.org/lkml/2018/1/5/405

----------

## mahdi1234

Hi,

I'm not sure but why is sys-kernel/gentoo-sources-4.14.12 having PAGE_TABLE_ISOLATION being dependent on X86_64?

Does it mean there never will be fix for x86 (32bits)?

I would like to understand this.

```
config PAGE_TABLE_ISOLATION

   bool "Remove the kernel mapping in user mode"

   depends on X86_64 && !UML

   default y

   help

     This feature reduces the number of hardware side channels by

     ensuring that the majority of kernel addresses are not mapped

     into userspace.

```

cheers ...

----------

## eccerr0r

I wish the "meltdown checker" had less dependencies so that it's easier to prove the older machines are equally affected.

----------

## josephg

http://github.com/torvalds/linux/blob/master/arch/x86/boot/compressed/pagetable.c says

```
/* No PAGE_TABLE_ISOLATION support needed either: */

#undef CONFIG_PAGE_TABLE_ISOLATION
```

----------

## mahdi1234

Ok, so the bottom line is 32bits are not affected by meltdown?

It's quite strage as Greg here http://kroah.com/log/blog/2018/01/06/meltdown-status/ says x86 ...

----------

## Pearlseattle

Thank you both!

----------

## gengreen

```
Unable to find symbol sys_call_table in /proc/kallsyms

Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.9.74-minipli...

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffff82201140 ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again).
```

It is really reliable ?

----------

## Pearlseattle

Fyi:

Alice (kernel maintainer) forwarded this URL:

https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre#sys-kernel.2Fgentoo-sources

Very useful - has the overview of the current status of the integration of KPTI into "gentoo-sources", and some more stuff.[/url]

----------

## krinn

it's usual to speak about x86 cpu as x86 without making the distinction between x86 and x86-64 cpus, because you speak about the architecture, which name was given by first cpu, the 8086. It's funny to say that your kick ass 16 cores cpu is just an 8086 on steroids  :Very Happy: 

you must also be use to this kind of shortcut : if you see them saying x86-64 are affect, it's all good for you no?

well it's not, amd x86-64 cpu are not affect, but you don't see a problem speaking about x86-64 that include them in that list.

----------

## Wallsandfences

I'm not sure I'm using the meltdownchecker correctly, but while compiling I get:

```
gcc meltdown_checker.cc

In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/immintrin.h:83:0,

                 from meltdown_checker.cc:43:

/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/rtmintrin.h: In Funktion »uint8_t probe_one_syscall_table_address_byte(uintptr_t, char*, int&)«:

/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/rtmintrin.h:50:1: Fehler: »inline« beim Aufruf von always_inline »unsigned int _xbegin()« gescheitert: target specific option mismatch

 _xbegin (void)

 ^~~~~~~

meltdown_checker.cc:122:24: Anmerkung: von hier aufgerufen

             if (_xbegin() == _XBEGIN_STARTED) {

                 ~~~~~~~^~

In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/immintrin.h:83:0,

                 from meltdown_checker.cc:43:

/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/rtmintrin.h:61:1: Fehler: »inline« beim Aufruf von always_inline »void _xend()« gescheitert: target specific option mismatch

 _xend (void)

 ^~~~~

meltdown_checker.cc:124:24: Anmerkung: von hier aufgerufen

                 _xend();

                        ^

```

----------

## josephg

you have to refer to the context to understand who means what when they say something. as krinn says, in this case greg is being inclusive. linus does not separate amd64 from x86 in his kernel architectures: http://github.com/torvalds/linux/tree/master/archLast edited by josephg on Sat Jan 06, 2018 10:44 pm; edited 2 times in total

----------

## khayyam

mahdi1234, et al ...

posted by Pearlseattle (in another thread): Vulnerabilities: Meltdown and Spectre (gentoo wiki) should help to answer that question.

HTH & best ... khay

----------

## The Main Man

Use make instead of gcc

----------

## khayyam

Wallsandfences ...

though your gcc speaks German fluently, many here do not ... which is why the use of LC_ALL=C is often a good idea :) ... anyhow, you should probably be using 'make' (as there is a Makefile included) rather than call gcc directly

```
# LC_ALL=C make
```

HTH & best ... khay

----------

## salmander

I test with meldown-checker and wonder i5 4670 isn't affected?

could this be false positiv? or can anyone explain this?

----------

## krinn

 *josephg wrote:*   

> linus separates amd64 from x86 in his kernel architectures: http://github.com/torvalds/linux/tree/master/arch

 

LOL good example because he did not, you must have mistake with arm64 or ia64 (which is use by itanium).

----------

## josephg

 :Smile:  good catch.. i misread that, now updated.

----------

## Wallsandfences

Sure, you're right, sorry.

Arrgh... 'make' it is, just spotted it...

```
./meltdown-checker

Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...

Checking syscall table (sys_call_table) found at address 0xffffffff81a00160 ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again).

```

But spectre is another matter... on AMD Athlon(tm) II X4 630 Processor

R.

----------

## Naib

32bit is affected

----------

## Spargeltarzan

I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"

Unfortunately still the old microcodes from 2017-04-09 become loaded. 

```
microcode: microcode updated early to revision 0xba, date = 2017-04-09
```

All files in /lib64/firmware/intel-ucode/* are created on 6. Jan. Same issue when I copy the microcode.cpio from /lib64/firmware/microcode.cpio to /boot.

I have added the microcodes in grub.cfg as initrd.

What am I doing wrong?

----------

## gengreen

 *Spargeltarzan wrote:*   

> I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"
> 
> Unfortunately still the old microcodes from 2017-04-09 become loaded. 
> 
> ```
> ...

 

Same issue....

----------

## Naib

have you tried baking the firmware upgrade into the kernel rather than using an initrc?  

I am about to build a new kernel with the ryzen img

----------

## pjp

 *Pearlseattle wrote:*   

> Hi
> 
> Which versions of "gentoo-sources" have gotten the patches against the "Meltdown"-attack?

 

 *mahdi1234 wrote:*   

> Hi,
> 
> I'm not sure but why is sys-kernel/gentoo-sources-4.14.12 having PAGE_TABLE_ISOLATION being dependent on X86_64?

 

Merged both Pearlseattle's and mahdi1234's threads.

----------

## Vrenn

I'm late on this threat to so please apologise. I know gentoo devs are now doing good (and probably heavy) work, I just want to tell my experience.

 *Spargeltarzan wrote:*   

> I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"
> 
> Unfortunately still the old microcodes from 2017-04-09 become loaded. 
> 
> 

 Same here:

```
eshowkw linux-firmware: [I]20180103-r1 amd64

iucode_tool -S -l /lib/firmware/intel-ucode/*

...

microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03

...

selected microcodes:

  049/001: sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528
```

Same old revision 0x22 is loaded. (naked BIOS-microcode-revision would be 0x1c, doublechecked)

```
/usr/src/linux # dmesg | grep micro

[    1.355964] microcode: sig=0x306c3, pf=0x20, revision=0x22

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

I have baking in the firmware ("intel-ucode/06-3c-03"-External firmware blobs to build into the kernel binary, "/lib/firmware"-Firmware blobs root directory, Haswell Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz)

Seems to be the same as on the beginning of the last year. The Gentoo-meltdown-wiki tells me it should be revision 3b?

of course I have compiled/installed the kernel new.

Either the wiki is wrong UNDERSTOOD by me with Revision 3b (they might mean with Haswell-X the Xenon-consumer-version of Haswell),

or there are different Haswell, not all getting new revision,

or intel/gentoo just not released the new revision for my cpu,

or I did something horrible wrong...

What might be true?

Edit: wiki is not wrong with Revision 3b I think, I just misread it.

----------

## Zazzman

 *kajzer wrote:*   

> Smells like a ploy to buy new hardware which will then have serious backdoors and kill switches.

 Of course. Or we could continue on hardware that discernibly has them now. Intel motherboards especially. https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668

 *Joseph Powers wrote:*   

> Can I patch the Meltdown bug with Gentoo hardened sources?

  Nice thought, but no.

 *kajzer wrote:*   

>  *eccerr0r wrote:*   Anyone have the PoC code, and whether disabling L1/L2 caches would mitigate the problem? PoC code :
> 
> http://cxsecurity.com/issue/WLB-2018010039

 Yes, this deserves being quoted so no one can bury their heads in the sand.

 *Atom2 wrote:*   

> Further information relating to XEN which just came through by E-Mail:
> 
>  *Quote:*   Hi all, this is a repost of https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ for xen-users/xen-devel. If you have questions, please reply to this thread and we will try and improve the FAQ based on questions.
> 
> Regards
> ...

 And here I was ready to dive into another Xen install. At least, before the ZFS update to 0.7.5 cooked my goose.

The Global Github hub for this mess: https://github.com/hannob/meltdownspectre-patches

As for mitigation:

Perfectly "fixing" these hardware glitches in software is impossible. But making them harder to exploit? Yeah, we can do that. At least, that's what GCC seems to think:

Spectre Variant 1: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00205.html

Spectre Variant 2: https://sourceware.org/ml/binutils/2018-01/msg00030.html

Or there's this variant of GCC: http://git.infradead.org/users/dwmw2/gcc-retpoline.git

And llvm: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html

https://lkml.org/lkml/2018/1/3/780

https://lkml.org/lkml/2018/1/4/615 (404s for me - maybe a better update is out there?)

Microcode updates are still pending, to my knowledge. Any chance a BDver2 or AMD fam15h firmware came out yet?

In the 'kernel hacking' section under 'memory hacking' there's an option to poison freed memory pages... I'm just sayin' this feels relevant for folks to double check.

I'm willing to throw an old 8core Piledriver at these gcc patches. It already runs gcc-7.2.0 globally under the 17.1 profile, and that unsupported "custom optimizations", "custom cflags", and "-jit" use flags are all enabled in my make.conf. This system is plenty stable under this setup. Or at least it was until the zfs-0.7.5 update hit with a bad handroll of my initramfs (plain dmcrypt on a zraid seemed to make this necessary). Time to start over, since the only place those keys now exist is inside the crypt, on a zraid! 0,__0, Screw it, I'm on my flash drive rescue install!

Even with KPTI, since "why the f*^k not? You expect these to be the only other problems out there that such fixes?" Para-nothing. Full-noid or bust. But the 'nopti' flag in grub's linux line turns off kpti like on any other distro.

I'm not quite sure how to add these patches to ebuilds for gcc and binutils. Otherwise I'd already be running them.

I'd love for *a* system to be covered by a 'emerge -NauvD --with-bdeps=y --complete-graph --emptytree @world' even if it isn't mine.

We *are* running the meta-distro. We *ARE* the guys, gals, etc that can take a pile o' parts and patches, and make freaking FIPS compliance look like a Joke! Are we gonna sit here, lamenting the false security we lost, or shall we patch boldly forward?

I'd be posting ebuilds if the toolchain's ebuilds would make that accessible. And if I knew how to clone sources through git in an ebuild (Somehow, that's not on any wiki entry I found). And so on and so forth. Come on team! Maybe this can be a teaching moment for some of us? I'm here to learn and patch. And I can't exactly patch any more without learning.

----------

## eccerr0r

I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.

However I noted, since

```
        config PAGE_TABLE_ISOLATION

        bool "Remove the kernel mapping in user mode"

        default y

        depends on X86_64 && !UML

        default y
```

Can we expect our 32-bit machines to be unsafe...for how long?  Or is this snippet a bit more confusing than it seems, since it has "default y" twice...

----------

## unheatedgarage

I just want to give a hearty, heartfelt shout-out to our Gentoo developers. Thank you for all your hard work!

----------

## depontius

 *eccerr0r wrote:*   

> I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.
> 
> However I noted, since
> 
> ```
> ...

 

I believe using PAE may make 32-bit machines safe, it does effectively the same thing for them - at a performance cost.

----------

## PrSo

NVIDIA is also affected:

http://nvidia.custhelp.com/app/answers/detail/a_id/4611

----------

## tholin

 *Spargeltarzan wrote:*   

> I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"
> 
> Unfortunately still the old microcodes from 2017-04-09 become loaded. 
> 
> 

 

My cpu i7-4790K (sig=0x306c3) didn't have any update in the 20171117_p20171215 update. The latest update was from the beginning of the year. Debian is shipping a .deb with newer microcode.

I downloaded it from http://ftp.us.debian.org/debian/pool/non-free/i/intel-microcode/intel-microcode_3.20171215.1_amd64.deb

That deb had a microcode update from 2017-11-20. I'm not sure if that is the right one for fixing "Variant 2: Branch target injection".

----------

## mv

 *depontius wrote:*   

>  *eccerr0r wrote:*   I just built 4.14.11-r2 for my general purpose workstation, which is an x86_64.
> 
> However I noted, since
> 
> ```
> ...

 

The point is that PAGE_TABLE_ISOLATION cannot be actived in 32 bit kernels, because the dependency X86_64 is not satisfied: The .config in 32 bit kernels does not even have that option.

So either the code is written such that it cannot run on 32 bit systems or it is not necessary (or the above dependency is a bug which I consider unlikely).

Unfortunately, the earlier mentioned meltdown test for does not compile for 32 bit x86 systems. (BTW, the spectre test does not compile, either).

Edit:  :Embarassed:  In the above text I had misunderstood that PAE should just mean a shortcut for PAGE_TABLE_ISOLATION. Only now I understand that it means another feature of 32 bit kernels.Last edited by mv on Sun Jan 07, 2018 8:02 pm; edited 1 time in total

----------

## albright

 *Quote:*   

> I have added the microcodes in grub.cfg as initrd. 

 

dumb question, but have you reloaded grub?

----------

## eccerr0r

 *depontius wrote:*   

> I believe using PAE may make 32-bit machines safe, it does effectively the same thing for them - at a performance cost.

 

That's what I speculated (ha) initially, but indeed this is still unconfirmed.  This still does not help one of my still somewhat used 32-bit laptop which corrupts memory when PAE is forced on (otherwise it claims PAE not available.)

----------

## tholin

Here is an important post by Andrew Lutomirski I stumbled upon on hacker news:

https://news.ycombinator.com/item?id=16087736

I'll quote the entire thing:

 *Quote:*   

> One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences.
> 
> 1. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x86 changes need to be backported, it'll be a huge mess.
> 
> 2. There is only minimal upstream support. I, for example, am already largely ignoring two bugs in the backports that aren't in the upstream version. Why? Because I have no affiliation with a distro using an old kernel.
> ...

 

The takeaway seems to be that kernel developers are ignoring bugs, including security bugs in the backports.

----------

## mike155

@thonlin: thanks for your post!

I wanted to run kernel 4.9 on my productive servers a little longer - but after reading Andy's post, I started to migrate all servers to 4.14...

----------

## transpetaflops

Doesn't this contradict the information given here?

https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre#sys-kernel.2Fgentoo-sources

----------

## eccerr0r

I recall a posting somewhere that running PTI on a VM really kills VM performance... has anyone seen such?  This sounds very concerning... Might have to look into containers and stop running a VM.

----------

## Pearlseattle

 *tholin wrote:*   

>  *Spargeltarzan wrote:*   I upgraded to the newest intel-microcode stabilized today "20171117_p20171215" and did "iucode_tool -S -l /lib64/firmware/intel-ucode/*"
> 
> Unfortunately still the old microcodes from 2017-04-09 become loaded. 
> 
>  
> ...

 

New version "20171117_p20171215-r1" of "sys-firmware/intel-microcode" has been released (contains updates as well for at least some non-X Intel processors => confirming that my i5-6200U loaded the update).

(https://bugs.gentoo.org/643794)

----------

## Thistled

Count yourself lucky.

I am stuck with a microcode update from 2010.   :Evil or Very Mad: 

I get the impression Intel won't be providing Wolfdales E5400 with any updates because they say they no longer support the chip.

What annoys me is the chip is fine, and my system runs great. There's nothing wrong with the chip for everyday use.

But, like the rest of the industry, you should be purchasing the latest "must have" every 6 months. Sucks.

----------

## The Main Man

Indeed, same here with the microcode from 2010, and I'm pretty happy with my old CPU, they will have to actually kill it before I buy new one  :Smile: 

One thing puzzles me though, when I load microcode with initramfs I get this :

```
$ dmesg | grep microcode                     

[    0.000000] microcode: microcode updated early to revision 0xa4, date = 2010-10-02

[    0.794279] microcode: sig=0x6fd, pf=0x1, revision=0xa4

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

When I include it in the kernel I get this :

```
dmesg | grep microcode                                                                                                                                                                                                

[    0.294653] microcode: sig=0x6fd, pf=0x1, revision=0xa1

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

Different revisions, depending on the method, I'm not able to figure this one out.

```
# iucode_tool -S -l /lib/firmware/intel-ucode/*                                                                                                                                                                 

iucode_tool: system has processor(s) with signature 0x000006fd

microcode bundle 1: /lib/firmware/intel-ucode/06-03-02

microcode bundle 2: /lib/firmware/intel-ucode/06-05-00

microcode bundle 3: /lib/firmware/intel-ucode/06-05-01

microcode bundle 4: /lib/firmware/intel-ucode/06-05-02

microcode bundle 5: /lib/firmware/intel-ucode/06-05-03

microcode bundle 6: /lib/firmware/intel-ucode/06-06-00

microcode bundle 7: /lib/firmware/intel-ucode/06-06-05

microcode bundle 8: /lib/firmware/intel-ucode/06-06-0a

microcode bundle 9: /lib/firmware/intel-ucode/06-06-0d

microcode bundle 10: /lib/firmware/intel-ucode/06-07-01

microcode bundle 11: /lib/firmware/intel-ucode/06-07-02

microcode bundle 12: /lib/firmware/intel-ucode/06-07-03

microcode bundle 13: /lib/firmware/intel-ucode/06-08-01

microcode bundle 14: /lib/firmware/intel-ucode/06-08-03

microcode bundle 15: /lib/firmware/intel-ucode/06-08-06

microcode bundle 16: /lib/firmware/intel-ucode/06-08-0a

microcode bundle 17: /lib/firmware/intel-ucode/06-09-05

microcode bundle 18: /lib/firmware/intel-ucode/06-0a-00

microcode bundle 19: /lib/firmware/intel-ucode/06-0a-01

microcode bundle 20: /lib/firmware/intel-ucode/06-0b-01

microcode bundle 21: /lib/firmware/intel-ucode/06-0b-04

microcode bundle 22: /lib/firmware/intel-ucode/06-0d-06

microcode bundle 23: /lib/firmware/intel-ucode/06-0e-08

microcode bundle 24: /lib/firmware/intel-ucode/06-0e-0c

microcode bundle 25: /lib/firmware/intel-ucode/06-0f-02

microcode bundle 26: /lib/firmware/intel-ucode/06-0f-06

microcode bundle 27: /lib/firmware/intel-ucode/06-0f-07

microcode bundle 28: /lib/firmware/intel-ucode/06-0f-0a

microcode bundle 29: /lib/firmware/intel-ucode/06-0f-0b

microcode bundle 30: /lib/firmware/intel-ucode/06-0f-0d

microcode bundle 31: /lib/firmware/intel-ucode/06-16-01

microcode bundle 32: /lib/firmware/intel-ucode/06-17-06

microcode bundle 33: /lib/firmware/intel-ucode/06-17-07

microcode bundle 34: /lib/firmware/intel-ucode/06-17-0a

microcode bundle 35: /lib/firmware/intel-ucode/06-1a-04

microcode bundle 36: /lib/firmware/intel-ucode/06-1a-05

microcode bundle 37: /lib/firmware/intel-ucode/06-1c-02

microcode bundle 38: /lib/firmware/intel-ucode/06-1c-0a

microcode bundle 39: /lib/firmware/intel-ucode/06-1d-01

microcode bundle 40: /lib/firmware/intel-ucode/06-1e-05

microcode bundle 41: /lib/firmware/intel-ucode/06-25-02

microcode bundle 42: /lib/firmware/intel-ucode/06-25-05

microcode bundle 43: /lib/firmware/intel-ucode/06-26-01

microcode bundle 44: /lib/firmware/intel-ucode/06-2a-07

microcode bundle 45: /lib/firmware/intel-ucode/06-2d-06

microcode bundle 46: /lib/firmware/intel-ucode/06-2d-07

microcode bundle 47: /lib/firmware/intel-ucode/06-2f-02

microcode bundle 48: /lib/firmware/intel-ucode/06-3a-09

microcode bundle 49: /lib/firmware/intel-ucode/06-3c-03

microcode bundle 50: /lib/firmware/intel-ucode/06-3d-04

microcode bundle 51: /lib/firmware/intel-ucode/06-3e-04

microcode bundle 52: /lib/firmware/intel-ucode/06-3e-06

microcode bundle 53: /lib/firmware/intel-ucode/06-3e-07

microcode bundle 54: /lib/firmware/intel-ucode/06-3f-02

microcode bundle 55: /lib/firmware/intel-ucode/06-3f-04

microcode bundle 56: /lib/firmware/intel-ucode/06-45-01

microcode bundle 57: /lib/firmware/intel-ucode/06-46-01

microcode bundle 58: /lib/firmware/intel-ucode/06-47-01

microcode bundle 59: /lib/firmware/intel-ucode/06-4e-03

microcode bundle 60: /lib/firmware/intel-ucode/06-4f-01

microcode bundle 61: /lib/firmware/intel-ucode/06-55-04

microcode bundle 62: /lib/firmware/intel-ucode/06-56-02

microcode bundle 63: /lib/firmware/intel-ucode/06-56-03

microcode bundle 64: /lib/firmware/intel-ucode/06-56-04

microcode bundle 65: /lib/firmware/intel-ucode/06-5c-09

microcode bundle 66: /lib/firmware/intel-ucode/06-5e-03

microcode bundle 67: /lib/firmware/intel-ucode/06-7a-01

microcode bundle 68: /lib/firmware/intel-ucode/06-8e-09

microcode bundle 69: /lib/firmware/intel-ucode/06-8e-0a

microcode bundle 70: /lib/firmware/intel-ucode/06-9e-09

microcode bundle 71: /lib/firmware/intel-ucode/06-9e-0a

microcode bundle 72: /lib/firmware/intel-ucode/06-9e-0b

microcode bundle 73: /lib/firmware/intel-ucode/0f-00-07

microcode bundle 74: /lib/firmware/intel-ucode/0f-00-0a

microcode bundle 75: /lib/firmware/intel-ucode/0f-01-02

microcode bundle 76: /lib/firmware/intel-ucode/0f-02-04

microcode bundle 77: /lib/firmware/intel-ucode/0f-02-05

microcode bundle 78: /lib/firmware/intel-ucode/0f-02-06

microcode bundle 79: /lib/firmware/intel-ucode/0f-02-07

microcode bundle 80: /lib/firmware/intel-ucode/0f-02-09

microcode bundle 81: /lib/firmware/intel-ucode/0f-03-02

microcode bundle 82: /lib/firmware/intel-ucode/0f-03-03

microcode bundle 83: /lib/firmware/intel-ucode/0f-03-04

microcode bundle 84: /lib/firmware/intel-ucode/0f-04-01

microcode bundle 85: /lib/firmware/intel-ucode/0f-04-03

microcode bundle 86: /lib/firmware/intel-ucode/0f-04-04

microcode bundle 87: /lib/firmware/intel-ucode/0f-04-07

microcode bundle 88: /lib/firmware/intel-ucode/0f-04-08

microcode bundle 89: /lib/firmware/intel-ucode/0f-04-09

microcode bundle 90: /lib/firmware/intel-ucode/0f-04-0a

microcode bundle 91: /lib/firmware/intel-ucode/0f-06-02

microcode bundle 92: /lib/firmware/intel-ucode/0f-06-04

microcode bundle 93: /lib/firmware/intel-ucode/0f-06-05

microcode bundle 94: /lib/firmware/intel-ucode/0f-06-08

selected microcodes:

  025/002: sig 0x000006f2, pf_mask 0x20, 2010-10-02, rev 0x005c, size 4096

  025/001: sig 0x000006f2, pf_mask 0x01, 2010-10-02, rev 0x005d, size 4096

  026/003: sig 0x000006f6, pf_mask 0x20, 2010-10-01, rev 0x00d1, size 4096

  026/002: sig 0x000006f6, pf_mask 0x04, 2010-10-01, rev 0x00d2, size 4096

  026/001: sig 0x000006f6, pf_mask 0x01, 2010-09-30, rev 0x00d0, size 4096

  027/002: sig 0x000006f7, pf_mask 0x40, 2010-10-02, rev 0x006b, size 4096

  027/001: sig 0x000006f7, pf_mask 0x10, 2010-10-02, rev 0x006a, size 4096

  028/001: sig 0x000006fa, pf_mask 0x80, 2010-10-02, rev 0x0095, size 4096

  029/007: sig 0x000006fb, pf_mask 0x80, 2010-10-03, rev 0x00ba, size 4096

  029/006: sig 0x000006fb, pf_mask 0x40, 2010-10-03, rev 0x00bc, size 4096

  029/005: sig 0x000006fb, pf_mask 0x20, 2010-10-03, rev 0x00ba, size 4096

  029/004: sig 0x000006fb, pf_mask 0x10, 2010-10-03, rev 0x00ba, size 4096

  029/003: sig 0x000006fb, pf_mask 0x08, 2010-10-03, rev 0x00bb, size 4096

  029/002: sig 0x000006fb, pf_mask 0x04, 2010-10-03, rev 0x00bc, size 4096

  029/001: sig 0x000006fb, pf_mask 0x01, 2010-10-03, rev 0x00ba, size 4096

  030/003: sig 0x000006fd, pf_mask 0x80, 2010-10-02, rev 0x00a4, size 4096

  030/002: sig 0x000006fd, pf_mask 0x20, 2010-10-02, rev 0x00a4, size 4096

  030/001: sig 0x000006fd, pf_mask 0x01, 2010-10-02, rev 0x00a4, size 4096

```

I've picked bundle 30 to include in the kernel, there's no revision 0xa1, anyone knows why this happens ?

----------

## eccerr0r

BTW, whoever can change the topic from "Meltdown/Spectre: Kernel Memory Leaking":

memory leak sort of means something ("malloc without free").

private memory content leakage or unauthorized memory read may mean something else...

just saying (yeah, I hate this term too, but I think it's well deserved for this topic.)

----------

## gengreen

Last firmware 20171117_p20171215-r1

```
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09

[    2.692722] microcode: sig=0x506e3, pf=0x20, revision=0xba

[    2.692854] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
```

Look better today, but still unable to known if I'm still vulnerable by meltdown

6 month they are aware of the problem and yet not capable to give a proper patch...

----------

## Naib

 *gengreen wrote:*   

> Last firmware 20171117_p20171215-r1
> 
> ```
> [    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
> 
> ...

 

For meltdown you need a patched kernel (grep secure /proc/cpuinfo)

For spectre you need gcc,kernel patching plus microcode for intel (gcc + kernel only for amd)

----------

## Wallsandfences

What am I missing? There wasn't a new gcc in the last few days??

----------

## Naib

 *Wallsandfences wrote:*   

> What am I missing? There wasn't a new gcc in the last few days??

 its not out yet... Spectre isn't resolved yet...

----------

## NeddySeagoon

That will be another 

```
emerge -e @world
```

 when the new gcc is out.

----------

## Naib

 *NeddySeagoon wrote:*   

> That will be another 
> 
> ```
> emerge -e @world
> ```
> ...

 Will it? or will it just be the kernel? I would have thought it would just be the kernel that needs to be rebuild with the new speculative branching mitigation (ie poisoning it)

----------

## luiztux

GCC 8 patch for Spectre...

----------

## EasterParade

Got patched kernel and updated microcode

```
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27

[    0.000000] Linux version 4.14.11-gentoo-r2 (root@aldebaran) (gcc version 6.4.0 (Gentoo 6.4.0 p1.1)) #2 SMP Sun Jan 7 10:09:37 CET 2018

```

I still see this:

```
grep secure /proc/cpuinfo

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

bugs            : cpu_insecure

```

Or is the patch in 4.14.11-r2 not complete yet?

----------

## Naib

 *transsib wrote:*   

> Got patched kernel and updated microcode
> 
> ```
> [    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
> 
> ...

 you will see that, that is just a verbose note that your CPU is classified as insecure. dmesg | grep -i isolation  should indicate whether the page table isolation is loaded

----------

## mv

 *Naib wrote:*   

> Will it? or will it just be the kernel?

 

Every program/library is vulnerable until recompiled with a gcc which has a corresponidng patch.

----------

## PrSo

 *Naib wrote:*   

>  *NeddySeagoon wrote:*   That will be another 
> 
> ```
> emerge -e @world
> ```
> ...

 

IMHO it is needed for Spectre v2 to recompile everything, but I am not sure about Spectre v1 tho:

https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

----------

## transpetaflops

 *gengreen wrote:*   

> Last firmware 20171117_p20171215-r1
> 
> ```
> [    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
> 
> ...

 

What is the source of these new microcode files? On Intel's website I can only find the original microcode file from 20171117 and none of the updated ones.

https://downloadcenter.intel.com/download/27337

----------

## Wallsandfences

I can confirm that the microcode works on meltdown for skylake u/y 

```
0x000406e3
```

----------

## krinn

google guys:

- "hey, we had rumour krinn is about to switch to profile 17.0"

- "ok release spectre and meldown papers to delay him more!"

----------

## Wallsandfences

 *Wallsandfences wrote:*   

> I can confirm that the microcode works on meltdown for skylake u/y 
> 
> ```
> 0x000406e3
> ```
> ...

 

Oops, on the next reboot it's gone. I can only speculate, since I updated my bios (intel nuc) and its revision is January the 3rd, that it got new microcode from bios now, skipping the early microcode patching.

R.

----------

## PrSo

This is another 3 in 1 meltdown-spectre mitigation checker:

https://github.com/speed47/spectre-meltdown-checker

It checks if any of the mitigations were applied.

On AMD apu , kernel 4.14.12-gentoo, without KPTI enabled in kernel config:

```
sh spectre-meltdown-checker.sh

Spectre and Meltdown mitigation detection tool v0.13

Checking vulnerabilities against Linux 4.14.12-gentoo #1 SMP Sun Jan 7 17:54:49 CET 2018 x86_64

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

* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 23 opcodes found, should be >= 70)

> STATUS:  VULNERABLE 

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 retpolines:  NO 

> STATUS:  NOT VULNERABLE  (your CPU is not vulnerable as per the vendor)

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 is not vulnerable as per the vendor)
```

----------

## krinn

latest microcode will be mark stable in a few, you can get it there if you don't want wait : 

https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-firmware/intel-microcode/intel-microcode-20171117_p20171215-r1.ebuild?id=fe65cc7bc14f41f05bb9c41f7318f280a1a31b5e

----------

## Naib

 *krinn wrote:*   

> latest microcode will be mark stable in a few, you can get it there if you don't want wait : 
> 
> https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-firmware/intel-microcode/intel-microcode-20171117_p20171215-r1.ebuild?id=fe65cc7bc14f41f05bb9c41f7318f280a1a31b5e

 Thats not new enough. That is Intels microcode from nov 2017... they have not made avail microcode for spectre ( well maybe to vendors for BIOS updates)

----------

## krinn

it's all we have for now, and i didn't myself check, but it's possible that a nov2017 update is indeed the fix.

spectre has been release to public jan2018, it doesn't mean intel has discover the issue that day  :Smile: 

and "not quiet sure", but i think devs have find and report the flaw in feb or march 2017.

at least from https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre

 *Quote:*   

> cpu:Haswell 	cpuid: 000306C3 	rev need: 0x23 

 

and i have  *Quote:*   

> >cpuid -1 | grep serial | tail -n1 | awk '{print $4}' | cut -d\- -f1,2 | sed 's/-//g'
> 
> 000306C3
> 
> >iucode_tool -S -l /lib/firmware/intel-ucode/*
> ...

 

----------

## Naib

Except...

Intel's PR release on 4th Jan:   https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/

 *Quote:*   

> Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. In addition, many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services.

 

Now the nov2017 update may have covered "products introduced within the past five years" as the press statement didn't actually state when that occured

----------

## mike155

 *PrSo wrote:*   

> This is another 3 in 1 meltdown-spectre mitigation checker:
> 
> https://github.com/speed47/spectre-meltdown-checker

 

This tool is pretty good! Thanks for sharing this. I'm especially glad it's only a shell script - and not a sophisticated C program. So I can see easily what it does.

I just executed it on a newly updated RHEL 7 server. It looks like they already have implemented LFENCE and IBRS in the kernel - here is the output:

```
Spectre and Meltdown mitigation detection tool v0.13

Checking vulnerabilities against Linux 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST 2017 x86_64

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

* Kernel compiled with LFENCE opcode inserted at the proper places:  YES  (112 opcodes found, which is >= 70)

> STATUS:  NOT VULNERABLE 

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

* Mitigation 1

*   Hardware (CPU microcode) support for mitigation:  NO 

*   Kernel support for IBRS:  YES 

*   IBRS enabled for Kernel space:  NO 

*   IBRS enabled for User space:  NO 

* Mitigation 2

*   Kernel compiled with retpolines:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines 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:  YES 

> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)
```

Last edited by mike155 on Mon Jan 08, 2018 1:32 pm; edited 3 times in total

----------

## EasterParade

 *Quote:*   

> ( well maybe to vendors for BIOS updates)

 

not holding breath; no UEFI update available since 2015 for this system (ASUS).

Broadwell systems have had updates only this year though.

----------

## Ant P.

 *PrSo wrote:*   

> This is another 3 in 1 meltdown-spectre mitigation checker:
> 
> https://github.com/speed47/spectre-meltdown-checker
> 
> It checks if any of the mitigations were applied.
> ...

 

I wonder if that's a side effect of Gentoo kernels not compiling in thousands of useless drivers. Maybe we're fine there.

----------

## khayyam

Add Snapdragon SoC to the list: Qualcomm Joins The CPU Affected List.

----------

## tholin

 *Naib wrote:*   

>  *NeddySeagoon wrote:*   That will be another 
> 
> ```
> emerge -e @world
> ```
> ...

 

Here is the way I see it, and I could be totally wrong. The information is spread over a lot of sites and patches.

To mitigate variant 2 you need to either recompile everything without indirect branches (retpolines solution) or update your kernel so it will flush the branch predictor on each context switch. Branch predictor flushing requires updated microcode. The needed microcode might be released but the upstream kernel support is not ready yet. Redhat and possible other vendors have rushed out patches already.

Retpolines doesn't work on recent intel cpus like Skylake so the only solution there is microcode. Intel said they released microcode update for cpus released within the last 5 year but what about older cpus? Unless there is a microcode update the only solution is retpolines afaik. Unfortunately rebuilding everything really means everything including the UEFI code. An attacker could play around with the branch predictor and then do something that causes UEFI to run. Since UEFI has access to all memory that could still leak everything.

Booting in legacy mode does not prevent UEFI from running but it might make it more difficult for an attacker to selectively run UEFI code. I'm not sure about that. Something else I'm not sure about is if the operating system can always guarantee that the branch predictor will be flushed before firmware code is run. When the operating system makes UEFI calls it can flush the branch predictor before but UEFI can also run because of obscure hardware interrupts. In that case you would need an update to the bios, not just microcode. 

In any case the variant 2 is difficult to exploit. The attacker needs know the layout and some content of the address space it wants to attack. As gentoo users we are lucky because the code we run is mostly unique to our systems. The firmware code is something an attacker could easily get from the vendors website but the attacker would have to create a separate exploit for each mobo/bios version combo. That's a lot of work so I don't think most home users have a lot to fear from variant 2 if the retpolines workaround is used alone. In the future the attack might be improved so I can't tell how long this will be true.

----------

## PrSo

 *Ant P. wrote:*   

> 
> 
> I wonder if that's a side effect of Gentoo kernels not compiling in thousands of useless drivers. Maybe we're fine there.

 

Please correct me if I am wrong, but with assumption that the kernel is crafted to my needs, and in accordance to:

- that the alternative to "legit retpoline" and "IBRS" on AMD cpu - "lfence" solution could be used:

https://lkml.org/lkml/2018/1/4/742;

- and migration in MSR was not fully implemented yet:

https://patchwork.kernel.org/patch/10146709/;

- PoC executed on my netbook says that its vulnerable to Spectre:

https://github.com/Eugnis/spectre-attack

in this perspective I think that we are not save yet but I wish I was wrong.

My intel NAS is another story touhg...

EDIT:

Above applies to spectre v2.

I have problems with LKML.org and could not read treads earlier.

There is a hot discussion about not to rely on "lfence" solution in resolving Spectre v1 problem on AMD cpu cause of slowdown impact.

https://www.spinics.net/lists/netdev/msg476433.html

I am starting to worry about performance downgrade.Last edited by PrSo on Mon Jan 08, 2018 9:27 pm; edited 1 time in total

----------

## Tony0945

It gets worse. Trust Wintel to take advantage: 

It gets worse: Microsoft’s Spectre-fixer bricks some AMD PCs

----------

## tholin

 *Naib wrote:*   

>  *krinn wrote:*   latest microcode will be mark stable in a few, you can get it there if you don't want wait : 
> 
> https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-firmware/intel-microcode/intel-microcode-20171117_p20171215-r1.ebuild?id=fe65cc7bc14f41f05bb9c41f7318f280a1a31b5e Thats not new enough. That is Intels microcode from nov 2017... they have not made avail microcode for spectre ( well maybe to vendors for BIOS updates)

 

Let's try checking that.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1578797.html

Assuming what is reported here is correct then "cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature

IA32_SPEC_CTRL ... { X86_FEATURE_SPEC_CTRL,        CPUID_EDX, 26, 0x00000007, 0 }"

sys-apps/cpuid can be used to read the cpuid.

```

$ dmesg |grep -m 1 microcode

microcode: CPU0 microcode updated early to revision 0x22, date = 2017-01-27

$ cpuid -1r

...

0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x00000000

...
```

So EDX is all zero and the needed feature is not in this microcode. Lets try the new version.

```

$ dmesg |grep -m 1 microcode

microcode: CPU0 microcode updated early to revision 0x23, date = 2017-11-20

$ cpuid -1r

...

   0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x0c000000

...
```

EDX is now 0x0c000000 with bit 26 set so the microcode from November appears to have the needed feature at least on my i7-4790K Haswell.

----------

## EasterParade

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

Spectre and Meltdown mitigation detection tool v0.13

Checking vulnerabilities against Linux 4.14.11-gentoo-r2 #2 SMP Sun Jan 7 10:09:37 CET 2018 x86_64

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

* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 27 opcodes found, should be >= 70)

> STATUS:  VULNERABLE 

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 retpolines:  NO 

> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines 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:  YES 

> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

```

Uh-Hu

----------

## Thistled

I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,

and yet even after applying the update via Portage, I am still on a 2010 microcode update. 

??

Intel® Pentium® Processor E5400 (2M Cache, 2.70 GHz, 800 MHz FSB) is in the list.

----------

## albright

I have three intel computers running gentoo with 

these cpus:  

i7-6700

i5-4300U

i7-6600U

the latter two are thinkpads

Loading the new intel microcode worked on the thinkpads:

for the 4300U:

```
dmesg | grep microco

[    0.000000] microcode: microcode updated early to revision 0x21, date = 2017-11-20

[    0.204333] microcode: sig=0x40651, pf=0x40, revision=0x21

```

for the 6700U:

```
dmesg | grep microco

[    0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16

[    0.262780] microcode: sig=0x406e3, pf=0x80, revision=0xc2
```

these two both show:

```
cpuid -1r:

edx=0x0c000000 
```

But the 6700 does not seem to take the update:

```
grep microco dmesg

[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09

[    0.324397] microcode: sig=0x506e3, pf=0x2, revision=0xba
```

and here:

```
cpuid -1r:

edx=0x00000000
```

Is there something about this chip - it did not get upated microcode, or what?

EDIT: I should add, all running kernel 4.14.12

----------

## Thistled

It seems they will be rolling out in batches all the microcode updates.

Seems applicable to all CPUs manufactured in the last 5 years.

The i7-6700 was produced in Q3-2015 so you will get the update sooner or later.

Just today there is another update to the microcode in Portage.

Suppose you just have to keep an eye out for it.

----------

## krinn

 *albright wrote:*   

> But the 6700 does not seem to take the update:
> 
> ```
> grep microco dmesg
> 
> ...

 

Look again more: https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre

 *Quote:*   

> Skylake H/S 	000506E3 	0xc2 

 

So it mean you use correct microcode for the two other, but as the link show you, the correct one should be 0xc2. Forget to emerge latest one?

----------

## albright

 *Quote:*   

> eix -I intel-microcode
> 
> [I] sys-firmware/intel-microcode
> 
>      Available versions:  20140430 (~)20140624 (~)20140913 20150121 (~)20150121-r1 20151106 (~)20160607 (~)20160714 20161104 20170511 20170707 (~)20171117 20171117_p20171215 20171117_p20171215-r1 {initramfs monolithic +split-ucode}
> ...

 

looks like the latest to me ...  (I could try the initrd route I guess ...)

----------

## krinn

albright: you are right, the wiki page seems incorrect with 0xc2

```
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3

  066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304

```

----------

## eccerr0r

BTW, in case it's not clear, x86 32-bit currently has no fix.  Upgrading to 4.14.12 will not protect from meltdown.

There was a comment about the "4GB/4GB memsplit" doing something to mitigate, alluded to in a twitter comment.  I also wonder if PAE does the 4GB/4GB split due to the nature of what is entailed getting PAE to work...

Due to instruction lack (clflush) of the old cpus, it may be harder to exploit this bug.  If you have SSE2, then you're still on the hook.

I suspect for those who are running 32-bit and have:

486, p5, p5mmx, atom N-series ... probably safe, carry on

ppro; p2; p3 ... continue the course, harder to exploit due to missing instructions for cache timing exploitation (see if you can run PAE if not already doing so)

p-m (banias, dothan) ... worry more (problems with PAE, might be SOL)

p4 (willamette, northwood)... worry more due to deep pipes (try running PAE)

p4 (prescott)... try to migrate to 64-bit if you can, else try running PAE

Core solo, core duo... try to migrate to 64-bit

atom D,Z-series (silvermont)... Try to migrate to 64-bit!

I don't know if it's valid to run 32-in-64... that would be another interesting situation...

----------

## fedeliallalinea

 *krinn wrote:*   

> albright: you are right, the wiki page seems incorrect with 0xc2
> 
> ```
> iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
> 
> ...

 

I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but

```
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4

  051/001: sig 0x000306e4, pf_mask 0xed, 2014-05-29, rev 0x0428, size 13312
```

with latest microcode 20171117_p20171215-r1

----------

## eccerr0r

Allright, I think I found more information about the 4GB/4GB split.

Apparently, unfortunately, the current incarnation of PAE does not have the so-called 4GB/4GB split.  This patch was suggested to kernel devs but not integrated.  The patch was introduced during the 2.5.X series and jettisoned before it made it into the kernel.

It completely maps out kernel space so that user programs can access the whole 4GB of address space, so your programs can fully use 4GB of RAM per process instead of running out of RAM at 3GB per process.  This has the side effect of preventing Meltdown.

So... 32-bit continues to be vulnerable with no solutions as of now, unless you happen to still use the experimental 4G/4G patch on an ancient kernel.

----------

## krinn

 *fedeliallalinea wrote:*   

> I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but
> 
> ```
> iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4
> 
> ...

 

intel latest provide microcode is https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=122139

Which is the "already" too old file that is use by 20171117_p20171215.

20171117_p20171215 -r1 have some microcode update, and that file comes from debian that took it from redhat.

You can see that file has "some update", here's the list from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367

```
     + Updated Microcodes:

       sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552

       sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432

       sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792

       sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528

       sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328

       sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648

       sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648

       sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384

       sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304

       sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

```

As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

So for now, if your cpu is in that list, you have an update.

----------

## fedeliallalinea

 *krinn wrote:*   

> As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.
> 
> So for now, if your cpu is in that list, you have an update.

 

Thank you krinn, now is clear!

----------

## The Main Man

 *Thistled wrote:*   

> I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,
> 
> and yet even after applying the update via Portage, I am still on a 2010 microcode update. 
> 
> ??
> ...

 

I think that's because they just say here's the latest archive for download with all cpu's microcode files inside, your cpu is on the list (like any that has microcode produced ever) but it doesn't matter that the date is 2017, for your cpu the microcode file date is 2010, they just pack all microcode files inside no matter if only one file was actually updated in that archive.

That's how I see it, could be wrong though.

----------

## Myu

So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...   :Evil or Very Mad: 

----------

## Thistled

Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user

to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit?

Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable

due to its age. Which could surely be mitigated by UPDATING the microcode?

Or am I missing something here, such as the age of the CPU means I DO have some level of mitigation?

This is a mess. Especially when the intel site states my CPU is covered by the latest microcode update. It clearly isn't.

I do know however that the TSX instruction set is not available in my CPU, so maybe Wolfdales are OK?

----------

## Myu

 *Quote:*   

> Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user
> 
> to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit? 

 

Could be, not in the US anyway but I'll be voting with my wallet if I need to purchase a new CPU and it's gonna be AMD.

 *Quote:*   

> Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable
> 
> due to its age. Which could surely be mitigated by UPDATING the microcode? 

 

I'm still holding up but like you, I would be really disappointed if there's no microcode update for older CPU's, my CPU is doing FINE, my OS of choice is already patched against meltdown, AFAIK all I need is the Microcode by now (and some other mitigations from GCC8/LLVM and other programs)

----------

## PrSo

 *Myu wrote:*   

> So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...  

 

I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from  2/2/2018. So there is a big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282Last edited by PrSo on Tue Jan 09, 2018 6:26 pm; edited 1 time in total

----------

## Myu

 *Quote:*   

> I think that intel will upgrade cpu microcode in waves.
> 
> I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that new bios will be available from 2/2/2018. So there is big probability that they will be sending microcodes for older families.
> 
> https://support.lenovo.com/us/en/solutions/len-18282

 

That's some valuable intel (ha!) you brought here PrSo, thanks, will keep an eye on this, all hope may not be lost.

----------

## Pearlseattle

 *PrSo wrote:*   

>  *Myu wrote:*   So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...   
> 
> I think that intel will upgrade cpu microcode in waves.
> 
> I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from  2/2/2018. So there is a big probability that they will be sending microcodes for older families.
> ...

 

This is as well my understanding.

More precisely, the promise is that by Sunday 14.Jan "Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" (stated here).

E.g. my "Xeon(R) CPU E3-1260L v5" hasn't been patched yet  :Crying or Very sad: 

----------

## dmpogo

To those of you who have patched/upgraded everything - can you comment on the performance,  is there a noticable hit ?

----------

## saboya

 *dmpogo wrote:*   

> To those of you who have patched/upgraded everything - can you comment on the performance,  is there a noticable hit ?

 

Unnoticeable outside synthetic benchmarks / very specific server usage.

----------

## PrSo

 *Pearlseattle wrote:*   

> 
> 
> E.g. my "Xeon(R) CPU E3-1260L v5" hasn't been patched yet 

 

Telling the truth I have no idea why because Lenovo System x3250 M5 has E3-1200 v3 which is older.

Lenovo page was modified couple of times. If I remember correctly update for t530 should be done firstly on 26th or 28th of January. Maybe it is Lenovo fault or maybe Intel plays on time. 

After bios update there could be a performance downgrade from 2% to 30% with current solution in software part, especially on servers.

If you apply Thistled's tin foil hat theory on that IMHO it comes to "money" or just to rework less resource-hungry way (I know that Intel and AMD were informed earlier about Meltdown and Spectre) and maybe those updated desktops/laptops cpu's are just the testing ground for code optimization. I presume that I could be wrong.

And that is a hell good question:

 *dmpogo wrote:*   

> 
> 
> To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ?

 

----------

## Aiken

 *eccerr0r wrote:*   

> I don't know if it's valid to run 32-in-64... that would be another interesting situation...

 

Do you mean 23 bit user space with a 64 bit kernel? Had a few 32 bit machines that I changed to a 64 kernel because I got fed up with the oom kill doing it's thing with low mem filling up while high mem and swap were mostly free. The only problem I had was the day I forgot to select 32 bit support in the 64 bit kernel and that machine promptly failed to boot. Nothing on those machines was in danger of hitting the address limit of 32 bit. Only reason I moved them to 64 bit user space was so I could use a single build server.

 *dmpogo wrote:*   

> To those of you who have patched/upgraded everything - can you comment on the performance,  is there a noticable hit ?

 

Cpu old enough to not get a microcode update and with the tool chain and statics libs now pie. These are my results on an old box I was testing with. Core2 e8500, 8G ram, 160G hd.

For a kernel compile was using the vanilla source for 4.14.11 and make oldconfig. 

running 4.9.72 it took 11 min 22 sec

running 4.14.11 it took 11 min 45 sec

running 4.14.12 with a pie tool chain 11 min 57 sec.

With a database only had a look at loading a database. 9.5 million lines in the dump and on disk space 1.2G. Running kernel 4.1.4.12.

boot pti=off a db load takes 2 min 31 sec

boot pti=on a db load takes 2 min 32.5 sec

Doing a dna sequence search with a ncbi-blast on the nt dna set I download november 21 the searches were 11 min 28 sec and 11 min 30 sec. That is not a good machine for doing searches at the best of times.

----------

## eccerr0r

 *Aiken wrote:*   

>  *eccerr0r wrote:*   I don't know if it's valid to run 32-in-64... that would be another interesting situation... 
> 
> Do you mean 23 bit user space with a 64 bit kernel?
> 
> 

 

Yes, except that the concern is whether the 32-bit userland gets the security advantage of the patched 64-bit kernel.  I would hope yes.  

This hack unfortunately does not work for the ppro, p2, p3, etc. as they do not have 64-bit execution cores...

----------

## Hu

Regarding the lack of older microcode, there are several plausible innocuous explanations:Perhaps some of the affected systems do so much of the work in pure hardware that a microcode fix is impossiblePerhaps the CPU's storage for microcode is too limited to accept the size increase that would come from augmenting the microcode with the fix.  Since microcode is the dumping ground for all such fixes, it tends to grow over time, and rarely if ever shrink for a given CPU.Perhaps the environment to build the microcode has bitrotted, and the vendor is no longer able to produce microcode for that chipPerhaps the vendor has other projects that they consider higher priority (possibly even rightly so), so the people qualified to write the microcode fix are busy doing other work

----------

## saboya

 *Hu wrote:*   

> Regarding the lack of older microcode, there are several plausible innocuous explanations:Perhaps some of the affected systems do so much of the work in pure hardware that a microcode fix is impossiblePerhaps the CPU's storage for microcode is too limited to accept the size increase that would come from augmenting the microcode with the fix.  Since microcode is the dumping ground for all such fixes, it tends to grow over time, and rarely if ever shrink for a given CPU.Perhaps the environment to build the microcode has bitrotted, and the vendor is no longer able to produce microcode for that chipPerhaps the vendor has other projects that they consider higher priority (possibly even rightly so), so the people qualified to write the microcode fix are busy doing other work

 

I think it's much more likely that they won't support processors after their EOL. I believe it's 5 years for Intel CPUs, so neither Sandy Bridge or Ivy Bridge should receive new microcodes.

----------

## Aiken

At least as far as meltdown goes even with the 32 bit user space I had expected meltdown to be dealt with using the an updated 64 bit kernel. I have one such system left. The checking tools not compiling under 32 bit does not help. This is a Prescott P4 and most of the checking I have done with it has been in a 64 bit chroot. I am getting mixed results. So far the Am-I-affected-by-Meltdown tool someone posted in this thread earlier has said it is safe no matter what kernel I have tried. Another tool looks for pti in the cpu cflags listed in /proc/cpuinfo. For me it is becoming academic as I am thinking time to retire that computer.

The core2 test box Am-I-affected-by-Meltdown gives the expected results depending on whether is booted with pti=on or pti=off.

Those sound like plausible reasons for no microcode update. I had taken the cynical approach and wondered how much of the decision was marketing with an arbitrary cut off date.

----------

## PrSo

New Intel microcodes:

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

and:

https://bugs.gentoo.org/show_bug.cgi?id=643794

----------

## fedeliallalinea

 *krinn wrote:*   

> As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

 

With intel-microcode-20180108 now is ok

```
$ dmesg | grep microcode

[    0.000000] microcode: microcode updated early to revision 0x42a, date = 2017-12-01

[    1.750161] microcode: sig=0x306e4, pf=0x4, revision=0x42a

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

----------

## fedeliallalinea

 *krinn wrote:*   

> albright: you are right, the wiki page seems incorrect with 0xc2
> 
> ```
> iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
> 
> ...

 

New version of microcode report 0xc2 for skylake

```
# iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3 

  066/001: sig 0x000506e3, pf_mask 0x36, 2017-11-16, rev 0x00c2, size 99328
```

----------

## Spargeltarzan

So in the microcode upgrade 2017-01-08 we can excpect microcodes as of 2017-11-16 in v2.2? Shouldn't it be 2017-01-08 as shown here? (When I click on my CPU it still shows 2017-01-08, but with the upgrade from today my microcodes become firstly upgraded to 2017-11-16. Crazy?

ADD: I have got an i7-6500U, Skylake, so I guess currently the 2017-11-16 is the latest in Gentoo Repos, but on Intel Page the 2018-01-08 is available. Hope it becomes available soon.

ADD: Output from spectre-meltdown-checker

```

Spectre and Meltdown mitigation detection tool v0.21

Checking for vulnerabilities against live running kernel Linux 4.14.12-gentoo #2 SMP Sat Jan 6 23:12:20 CET 2018 x86_64

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

* Checking count of LFENCE opcodes in kernel:  NO  (only 32 opcodes found, should be >= 70)

> STATUS:  VULNERABLE  (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:  YES 

*   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:  YES 

> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

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

```

I see cpu microcode is not vulnerable any more, so probably this was already fixed by microcodes v2.2 - 2017-11-16? 

Is my test result the maximum fix at the moment?

----------

## mike155

 *Quote:*   

> Is my test result the maximum fix at the moment?

 

Probably not. Look at the output from a RHEL 7 server I posted two days ago. The tool indicates that they already have Kernel support for IBRS and LFENCE opcodes.

----------

## krinn

Here are results on my testing:

the variant 1 : i don't have the fix for that yet.

the variant 2 : microcode has fix it

the variant 3 : KPTI should fix it (i have KPTI, but nothing to test it).

the spectre and update spectre-thread spoke earlier are variant1 (and yes, they do work flawlessly)

the meltdown earlier is variant2 : (with the microcode update it fail, without it, it work)

on my core2 using x86: variant1 test fail, variant2 test fail (i even cannot build them, but my corei2 as done the job with -m32)

i also prefer those two tools, because they don't check your security, they just try to abuse you : no need for a script telling me: ok your microcode is update if anyone could still fuck me with that microcode.

expect variant1 virus incoming  :Smile: 

guys: i suppose we have to find those IBRS LFENCE ready kernel.

----------

## blopsalot

FYI : I''ve been testing Gentoo Hardened Profile devices using the following the projects and I don't see it working on processors reported as vulnerable on other distros, kernels predate the Page Table/Kaiser inclusion.

https://github.com/paboldin/meltdown-exploit

reports not vulnerable on all tested

https://github.com/IAIK/meltdown

this one says it finds the offset of KASLR (its wrong). inputting correct offset, the reliability test is .4% and I still cannot read values from ./secret

https://github.com/Eugnis/spectre-attack

this one works at default but i don't see it sucessfully reading anything else

----------

## Aiken

The 2 newer desktops (i7 700k) got microcode updates from both 20171117_p20171215-r1 and 20180108. Everything else is outside that 5 year limit.

Anyone been trying kvm on older hardware? On the core2 having kpti enabled in the guest is a killer. Timing a kernel compile I am getting

Host 11 1/2 - 12 minutes depending on booting with pti=on/pti=off

Host pti=off, guest pti=off 21 - 25 min

Host pti=on, guest pti=off 27 min

Host pti=on, guest pti=on 41 - 53 min

This is hw old enough to not have the pcid instruction. At least on the older hw can not say I am happy if kpti gets enabled in the guest.

----------

## blopsalot

 *blopsalot wrote:*   

> FYI : I''ve been testing Gentoo Hardened Profile devices using the following the projects and I don't see it working on processors reported as vulnerable on other distros, kernels predate the Page Table/Kaiser inclusion.
> 
> https://github.com/paboldin/meltdown-exploit
> 
> reports not vulnerable on all tested
> ...

 

this one works, other two seem broken. im prett sure it had to do with catching the right cpu, but i'm still unsure. https://github.com/IAIK/meltdown

----------

## PrSo

Hi krinn,

as for Spectre v1 IMHO it is to early to adapt those patches, this is still a WIP and not even in linus git tree yet. 

Lately Fedora has adopted them and I suppose that RHEL too as mike155 sad, but  from the mailing list - those patches have problems i.e. during build on arm:

https://www.spinics.net/lists/netdev/msg477230.html

As the first commit says this series can be found on github:

https://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux.git/?h=nospecLast edited by PrSo on Thu Jan 11, 2018 5:14 pm; edited 1 time in total

----------

## queen

Hi Guys

With all the mess of the latest vulnerabilities, I decided not to upgrade the kernel and install all the new firmware, microcode etc. It's a totally waste of time, because the problem won't be solved anyway until they develop a new CPU(which will take around 5 years as a person from Intel told me). And definitely the performance will be affected.  My question is how other packages will be affected? 

What other packages might be affected (gcc)? emerge world? Normal programs will be affected?

----------

## Spargeltarzan

@ queen:

At least you can protect against Meltdown.

Further, I believe a Spectre upgrade which close this issue is possible. There are some performance test comparisons which differ from almost no hit to significant hit, let's wait a bit here. Desktop PCs might be less affected anyway.

All in all, do you have an alternative to upgrade currently, do you prefer abuse of your data?

----------

## queen

Well, I heard the lecture of Daniel Genkin (one of the authors of the paper) this week. He said spectre will haunt us for years. Furthermore, one of the greatest cpu architests that worked until recently at intel said that it needs a new design of cpu which will take 5 years. So don't be naive about spectre. I might consider applying kaiser.  Unfortunately, our data is abused all over.  :Crying or Very sad: 

BTW, the person who worked at intel, told me that they designed about 10 years ago a cpu that would have resolved some of the issues that were presented now, but intel refused it because the performance was only 10% and intel wanted only performance. The guy is a genius.

----------

## The Main Man

Spectre and Meltdown aside, who knows what else is there that we don't know about.

----------

## Myu

Intel CPU's older than 5 years should get microcode security fixes : https://newsroom.intel.com/news-releases/security-first-pledge/

 *Quote:*   

> 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

 

----------

## eccerr0r

 *Myu wrote:*   

> Intel CPU's older than 5 years should get microcode security fixes : https://newsroom.intel.com/news-releases/security-first-pledge/
> 
>  *Quote:*   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 

 

Actually it probably meant, 

90% of the last 5 years CPU: by Jan 15

10% of the last 5 years CPU: by Jan 31

100% of older than 5 years: SOL

ugh, don't know what to do about my Sandybridge i7...

 *queen wrote:*   

> BTW, the person who worked at intel, told me that they designed about 10 years ago a cpu that would have resolved some of the issues that were presented now, but intel refused it because the performance was only 10% and intel wanted only performance. The guy is a genius.

 

I wonder if they meant Itanium since apparently it was not affected, and it wasn't just Intel that wanted performance, it's the customer that wanted performance and binary compatibility (power consumption comes later I suppose)...

----------

## PrSo

@ eccerr0r

 *Quote:*   

> Customer-First Urgency: 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.

   :Wink: Last edited by PrSo on Thu Jan 11, 2018 6:11 pm; edited 1 time in total

----------

## mike155

The important word is "introduced" - and it was carefully chosen. It does not mean: "delivered" or "sold".   :Sad: 

----------

## Tony0945

 *Quote:*   

> remainder of these CPUs available by the end of January

  Not remainder of our CPU's. It's clearly referring to CPU's from the last five years.

----------

## blopsalot

 *Tony0945 wrote:*   

>  *Quote:*   remainder of these CPUs available by the end of January  Not remainder of our CPU's. It's clearly referring to CPU's from the last five years.

 

Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves."

----------

## Tony0945

 *blopsalot wrote:*   

> Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves."

 

A safe interpretation.

----------

## PrSo

Maybe I am wrong, but IMHO reading paragraph as one thought, as a whole, you should think about it as "scheduling amendments releases".Last edited by PrSo on Thu Jan 11, 2018 10:07 pm; edited 2 times in total

----------

## transpetaflops

 *Tony0945 wrote:*   

>  *blopsalot wrote:*   Yeah I took this part "We will then focus on issuing updates for older products as prioritized by our customers." as "If we get hassled by other large corporations to fix certain older products, we will. Everyone else can go $#@# themselves." 
> 
> A safe interpretation.

 

This wouldn't be consistent with past Intel behaviour. Two previous incidents come to mind. With the Pentium FDIV bug they offered to replace every faulty CPU and with the faulty RDRAM MTH they replaced every motherboard and even included working memory. These are examples of taking responsibility which has made me stick to Intel for the past 30 years. I fully understand that there's no practical way they can replace every Intel CPU out there this time but I expect them to provide updated microcode, even for CPUs older than 5 years. If the financial burden for this would be overwhelming, I would accept to pay a nominal fee to have my older CPUs updated.

----------

## krinn

It's not because you deploy update kernels and fix on all "latest" cpu in your network, that it is ok to have your network fuck because that poor little server that doesn't need better than its "old" cpu to do its job, can be use to leak informations that will destroy your network security.

They have lot of work to do, and it will take time, they are putting time on newer cpu, because logically more used.

But it doesn't mean older "affected" cpu will be kept affected, even it's true they will be handle as second class citizens.

All big structures have such kind of computer running, because they do the job and don't need any upgrade cpu do keep doing it.

And obviously, there's no security in putting steel doors in an house with open windows.

----------

## eccerr0r

One thing companies have done in the past is give vouchers for "latest and greatest" which is unacceptable for many installations (due to revalidation costs, etc.) ... 

Anyway, despite it being able to leak information, with ASLR, other than scanning the whole memory for accessing juicy bits, are there fixed address tables that can be used to pinpoint specific information in O(1) instead of O(n)?

I still use 32-bit... this really irritating.

----------

## mike155

Aiken: thanks for your performance measurements. I was shocked by the performance degradation you reported - especially since patches for Spectre have not even been merged.

I tried to repeat your measurements. Here are my results for time emerge -B glibc >/dev/null running in a QEMU VM on a Intel Xeon CPU E3-1245 V2 host:

```
-------------------------------+---------------------+--------------+------

Kernel & config                | time [s]            | mean [s]     | rel. 

of QEMU VM                     | (3 measurements)    |              |  

-------------------------------+---------------------+--------------+------

4.9.65 as of Nov. 2017         | 320.8, 320.9, 320.7 | 320.8 ± 0.1  | 100%

4.14.13, CONFIG_PTI=no,        | 324.2, 324.6, 325.0 | 324.2 ± 0.4  | 101%

4.14.13, CONFIG_PTI=yes, nopti | 327.2, 326.6, 325,3 | 327.2 ± 1.0  | 102%

4.14.13, CONFIG_PTI=yes, pti   | 411.7, 417.4, 412.7 | 411.7 ± 3.0  | 128%

-------------------------------+---------------------+--------------+------

Remarks:

- CONFIG_PTI: kernel configuration parameter 'CONFIG_PAGE_TABLE_ISOLATION'

- pti, npti: kernel command line parameter

- Host: Intel Xeon CPU E3-1245 V2, x86_64, 32GB Ram, Kernel 4.14.12, pti

- Qemu: 2.10.1-r1, virtio devices

- Guest: 2 Core x86_64, 4 GB RAM, /var/tmp is tmpfs

```

The test shows a performance degradation of nearly 30% (!) for Linux systems running in a QEMU VM. This degradation will probably become worse after Spectre patches have been merged.

The difference between pti and nopti for a Linux kernel 4.14.13 running on bare metal is only 3% - 5%.

Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?

----------

## mahdi1234

 *eccerr0r wrote:*   

> 
> 
> I still use 32-bit... this really irritating.

 

I second this ... does it mean we're thrown away to die now?

The silly thing is gentoo doesn't really have 32 --> 64 path other than fresh install ... but I DO NOT BLAME gentoo here, just to be clear ... the whole situation just shows some animals are more equal, the story goes on farewell to all our dreams.

----------

## Naib

 *mahdi1234 wrote:*   

>  *eccerr0r wrote:*   
> 
> I still use 32-bit... this really irritating. 
> 
> I second this ... does it mean we're thrown away to die now?
> ...

 it's not a gentoo issue, its an OS issue.  If you boot a 32bit kernel it can only deal with 32bit instructions (as it switching the cpu to 32bit mode)  so you are not in a position to execute 64bit instructions.

if you had a complete 32bit system and de-compressed a 64bit stage3 over your base system BUT then you have essencially polluted your system with what the 32bit kernel can only interpret as binaries with illegal instructions... you wouldn't be able to shutdown, open things etc... Lets say you did manage a clean shutdown what kernel would you then boot with? you only have a 32bit kernel and init would then segfault 

The best solution is a clean install. The next best solution is booting off a sysrescue CD/USB with its 64bit kernel, de-compressing a 64bit stage3 over your /<root>, chroot into this messed up system, recompile your kernel so it is now 64bit & then do an emerge -e @world to rebuild your entire system

----------

## Pearlseattle

Fyi just to recap about my CPUs:

i5-6200U (000406E3) patched with sys-firmware/intel-microcode-20171117_p20171215-r1

E3-1260L v5 (000506E3) patched with sys-firmware/intel-microcode-20180108

E3-1271 v3 (000306C3) (which I think are a relatively big bunch of servers on hetzner.de) haven't been patched yet (my current microcode still stuck to "0x1d" after having downloaded "sys-firmware/intel-microcode-20180108-r1")   :Crying or Very sad: 

Didn't check yet other servers/PCs as low priority... .

----------

## Aiken

 *mike155 wrote:*   

> 
> 
> Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?

 

Repeated the same test on an i7 7700k with ssd. The run time on the i7 was not long enough to get a good % time difference. 22 seconds with no kpti in the guest and 22 - 23 seconds with kpti in the guest. On the i7 I let qemu have all 4 cores. Only difference I noticed was on the host where cpu load was higher with host + guest having kpti on vs off and no danger of running out of cpu. Storage was a 20G file. 22 seconds on the i7 vs a min of 21 minutes on the core2.

On the core2 letting qemu use both cores I think the host was running out of cpu. Watching top both the sy and wa columns are higher with kpti on. It was spending a lot more time in syscalls and waiting for io. Also the core2 does not have the pcid instruction which a few things on the net say helps with any speed loss. For storage with qemu tried both a 20G file and a 20G slice on lvm.

The machine I want to run kvm on is still at 3.14.17 due to some old stuff that is still in use and not wanting to touch something that "just works". It is an i5 2500k, has the pcid instruction, faster ram, still hard drives instead of ssd. Not sure what it will be like. My take away from this is while the core2 is still overkill for general use for some people I know forget about using it as a kvm server.

 *Naib wrote:*   

> 
> 
> it's not a gentoo issue, its an OS issue.  If you boot a 32bit kernel it can only deal with 32bit instructions (as it switching the cpu to 32bit mode)  so you are not in a position to execute 64bit instructions.
> 
> 

 

It is not hard to do a 32 to 64 bit conversion. The 1st thing is install crossdev to build a 64 bit tool chain to build a 64 bit kernel. Have done a few 32 to 64 conversions. A mistake will leave a person needing their favourite install media. The worst bit I found was the apprehension after typing reboot on the headless boxes.

----------

## EasterParade

For the new gcc revision I started a emerge -e @world for test purposes only.

After one hour only 280 packages have been compiled. 

I don't know % but performance drop is palpable.

----------

## NeddySeagoon

transsib,

Ask genlop if you want a wall time comparison.

Its not very scientific as its elapsed time for a build, which varies with whatever else is going on at the time.

----------

## PrSo

I will wait with microcode update. They F***** smth up :

https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

EDIT:

Affected chips Broadwell and Haswell. That must be the reason of delay for some CPUs.Last edited by PrSo on Fri Jan 12, 2018 5:10 pm; edited 3 times in total

----------

## EasterParade

NeddySeagoon, will try genlop next time I start this experiment.

Will have to interrupt it soon because I don't wanna have it run all night long.

I know I can trust my feeling though; before the patch more than twice as many packages

have been done within the same time.

Also I'm not certain if I have the current microcode for my Haswell Xeon(R) CPU E3-1240 v3:

```
# dmesg | grep micro

[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27

[    0.498616] microcode: sig=0x306c3, pf=0x2, revision=0x22

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

----------

## NeddySeagoon

transsib,

You can use 

```
genlop -t
```

 any time.  It parses elapsed times from /var/log/emerge.log 

Your entire emerge history should be there.

-- edit --

date = 2017-01-27  may be the current microcode but its too old for the latest round of security fixes.

----------

## krinn

 *transsib wrote:*   

> Also I'm not certain if I have the current microcode for my Haswell Xeon(R) CPU E3-1240 v3:
> 
> ```
> # dmesg | grep micro
> 
> ...

 

-> 

```
[    0.444478] microcode: sig=0x306c3, pf=0x2, revision=0x23
```

----------

## EasterParade

NeddySeagoon, which package has genlop; my system doesn't know the command.

Krinn, current microcode doesn't load. Looks like I need to do 

```
iucode_tool -S --write-earlyfw=/boot/early_ucode.cpio /lib/firmware/intel-ucode/*
```

again ( updated to sys-firmware/intel-microcode-20180108) unless it gives "cannot write - file exists"  ?

It's almost tragic because no effort completely safeguards our systems. 

And if you think spending money for a new system would do the trick don't get your hopes up

because  *spoilers* no existing CPU is safe. 

May be we are all part of the problem because we all wanted fast systems. We got fast systems

at cost of security.

----------

## Naib

```

 eix genlop

[I] app-portage/genlop

     Available versions:  0.30.9-r1 (~)0.30.10 (~)0.30.10-r1 **9999

     Installed versions:  0.30.10-r1(12:56:09 14/05/17)

     Homepage:            https://wiki.gentoo.org/wiki/Project:Perl

     Description:         A nice emerge.log parser

```

----------

## Spargeltarzan

Does gcc-r1 have something todo with spectre?

----------

## keet

 *mike155 wrote:*   

> Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM? Does this happen only with QEMU? Or does it happen also with VMWare? Do we have to live with that? Or is it something that can be fixed in the kernel or in QEMU?

 

Might this be related?

"As the fixes for CVE-2017-5715 will also need adjustments in the QEMU virtualization host to pass through CPUID flags and MSRs from host to guest system, Gentoo will also be providing an updated app-emulation/qemu package once available. You can subscribe to bug #643432 to get notified or wait for the GLSA release.  Note that the XEN Hypervisor also needs mitigations for the described problems, the XEN team is currently developing a fix. You can subscribe to bug #643350 to get notified or wait for the GLSA release."

----------

## EasterParade

Spargeltarzan, there's no fix against Spectre.

Also each and every patch applied by us now will only mitigate any 

possible unknown danger.

----------

## Spargeltarzan

I understand... 

So the mitigations in CentOS/RHEL and iOS are protective mechanisms how Spectre could be used, but different malware, trying a new approach, could succeed? Too bad that we even can't quit Intel and by AMD instead. And I even dont want to think on my android phone, which will even not get Android 8 any more and Android Security Updates are also only September 2017.

We try too secure our Gentoo Boxes as much as we can and than we suffer from a java script Google Chrome exploit on Android on the phone which contains more sensitive data than my Gentoo Box. It sucks.

----------

## EasterParade

The patch only addresses and mitigates Meltdown.

----------

## Spargeltarzan

On the blog of iOS they write " To help defend against Spectre, Apple has released mitigations in iOS 11.2.2, the macOS High Sierra 10.13.2 Supplemental Update, and Safari 11.0.2 for macOS Sierra and OS X El Capitan." Blog and the same for RHEL: here they have "fixes" for all 3 types of vulnerabilities

----------

## mike155

Current status of Linux kernel patches regarding Meltdown / Spectre: https://marc.info/?l=linux-kernel&m=151579356820020&w=2

 *Thomas Gleixner wrote:*   

> ... To be honest the last 10 days were more horrible than the whole PTI work
> 
> due to lack of documentation, 12 different opinions when asking 8 people
> 
> (why does this have a lawyer smell?) and an amazing amount of half baken
> ...

 

----------

## gengreen

```
sys-firmware/intel-microcode 20180108-r1
```

```
[0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16

[    2.700454] microcode: sig=0x506e3, pf=0x20, revision=0xc2

[    2.700562] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
```

Gcc has release a -r1 update, after the emerge of this

```
emerge -e @world
```

Will do ? I have to rebuilding my kernel with the new gcc patched as well ?

Thanks,

----------

## mike155

 *Spargeltarzan wrote:*   

> Does gcc-r1 have something todo with spectre?

 

As far as I can see: no

The difference between gcc-6.4.0 and gcc-6.4.0-r1 is:

```
95_all_static_override_pie.patch

96_all_powerpc_pie.patch

97_all_libjava-ucontext.patch
```

These patches are not related to Meltdown / Spectre.

----------

## mike155

 *gengreen wrote:*   

> emerge -e @world

 

Why do you want to rebuild your world? What do you want to achieve?

----------

## pjp

 *mike155 wrote:*   

> Current status of Linux kernel patches regarding Meltdown / Spectre: https://marc.info/?l=linux-kernel&m=151579356820020&w=2
> 
>  *Thomas Gleixner wrote:*   ... To be honest the last 10 days were more horrible than the whole PTI work
> 
> due to lack of documentation, 12 different opinions when asking 8 people
> ...

  And on that note, I was about to ask for some clarification.

I keep seeing comments similar to AMD isn't affected by Meltdown, which I associated with the kernel option "CONFIG_PAGE_TABLE_ISOLATION=y" not being needed for AMD CPUs.

Am I mistaken?

I'm asking for two reasons. First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted. That's fine, but doesn't explain what C_P_T_I is actually doing.

Which brings me to the second reason I'm seeking source clarification:

 *Meltdown vulnerability and KPTI wrote:*   

> AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.

  Emphasis added.

----------

## gengreen

 *mike155 wrote:*   

>  *gengreen wrote:*   emerge -e @world 
> 
> Why do you want to rebuild your world? What do you want to achieve?

 

I tought this new update of gcc was about the new feature that will help against meltdown/spectre. 

Anyway, when the update of gcc will have some protection for meltdown/spectre, rebuilding my entire system to have the full benefit of it, is what I should do no ?

----------

## NeddySeagoon

gengreen,

The fixes are not yet completely in place and some details remain to be worked out.

The honest answer today is that nobody knows for sure.

It may be enough to rebuild the kernel to improve the mitigation.

You need a new kernel and new microcode built with your current gcc now but maybe not if you have AMD.

See the questions pjp is asking.

A patch to gcc to address meltdown/spectre will be a minor version bump from gcc upstream, not a -rx bump from gentoo.

Look for gcc-6.5 or gcc-7.3 and the like.

----------

## gengreen

 *NeddySeagoon wrote:*   

> gengreen,
> 
> The fixes are not yet completely in place and some details remain to be worked out.
> 
> The honest answer today is that nobody knows for sure.
> ...

 

Thank you for those details. You are right, I should use the term, mitigation instead of protection.

I'm a lucky possessor of a i7 intel Skylake, fully compatible with meltdown and spectre  :Razz: 

intel-microcode is updated, kernel not yet, using a non-standard one (minipli) which haven't release an update for meltdown. 

Regarding Gcc when the version 6-5 or 7-3 will be release,  

```
emerge -e @world
```

 could improve, even if it is minor, the mitigation against meltdown/spectre ?

Planning to buy a new laptop in few month, Intel will be out of buying list (Meltdown/Spectre aren't the only reason why, just the trigger).

----------

## mike155

 *pjp wrote:*   

> First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted.

 

Here are the sources that I know of:

1) Mail from Tom Lendacky (AMD). His explanation seems plausible, but we can't do more than believe him.

2) Linux kernel commit message: "Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead"

----------

## PrSo

 *pjp wrote:*   

> 
> 
> I'm asking for two reasons. First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted. That's fine, but doesn't explain what C_P_T_I is actually doing.
> 
> 

 

Second that, but I think that you are asking about things restricted under patent protection and other information which constitutes the company secret and cannot be made generally available.

 *pjp wrote:*   

> Which brings me to the second reason I'm seeking source clarification: 
> 
> Meltdown vulnerability and KPTI napisał:
> 
> AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.

 

Personally I think that the second question needs an explanation of CPU engineer with exact knowledge of AMD CPU architecture including mentioned above company secrets which could not be answered without making him a breacher.

I think that in this situation we have to trust Tom Lendacky and AMD for now.

----------

## pjp

 *mike155 wrote:*   

>  *pjp wrote:*   First, I haven't seen a source for this claim other than that supposedly AMD says they aren't impacted. 
> 
> Here are the sources that I know of:
> 
> 1) Mail from Tom Lendacky (AMD). His explanation seems plausible, but we can't do more than believe him.
> ...

  Thanks. I have seen those. Given the date, the first message didn't seem necessarily definitive, which then made Linus' comment seem a bit like "if you say so."

But like I said, that's fine. Then there's the KASLR issue which the wikipedia page seems to relate to the page isolation table setting, which contradicts the claims or perception that AMD doesn't need the setting. So I guess it is mainly the KASLR issue I'm wondering about.

I have searched, but most links seem more noise than signal.

----------

## pjp

 *PrSo wrote:*   

> Second that, but I think that you are asking about things restricted under patent protection and other information which constitutes the company secret and cannot be made generally available.

  Yeah, I can accept that. It is mainly how it relates to my second query.

 *PrSo wrote:*   

>  *pjp wrote:*   Which brings me to the second reason I'm seeking source clarification: 
> 
> Meltdown vulnerability and KPTI napisał:
> 
> AMD x86 processors are not currently known to be affected by Meltdown and don't need KPTI to mitigate them.[13][24] However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled. 
> ...

  Sure. With this event being released / announced in the way it has, the messaging seems to lack clarity. And I haven't seen much related to KASLR (it could be in one of the CVEs, which would demonstrate why marketing names for vulnerabilities is a Bad Idea).

----------

## Hu

 *pjp wrote:*   

> doesn't explain what C_P_T_I is actually doing.

 CONFIG_PAGE_TABLE_ISOLATION=y builds and default-enables code that, if not disabled at boot time via kernel command line, removes many (but not all) kernel page table entries prior to running user code, then restores those page table entries when entering kernel mode.  The commonly accepted code sequence for exploiting Meltdown requires that the page table entry for the kernel code/data be present, since affected CPUs can speculate past the permission restriction (reading in user mode a page that was marked as kernel-access-only), but cannot speculate a read when the entry is missing entirely, since it needs that page table entry to tell it what physical page to read.  With the PTE wholly absent, it cannot tell where to speculatively read, so it doesn't read at all, and the Meltdown exploit fails.

 *pjp wrote:*   

>  *Quote:*   However, AMD processors are still susceptible to KASLR bypass when KPTI is disabled.  Emphasis added.

 As I understand the underlying research, this KASLR bypass is implemented as:Perform an expected-to-fail read of an address which may be unmapped or may be mapped as kernel-only.After it fails, try again.If the second failure is as slow as the first, it is (probably) because the address is unmapped, so the CPU performed a full page table walk each time.If the second failure is faster, it is because the CPU had copied the kernel-only page table entry into the TLB while resolving the first fault, and so is able to quickly determine that access is still not allowed.This technique was believed only to serve as a tri-state classifier of whether the page was: readable-to-user (and kernel), readable-to-kernel (but not user), unreadable-to-all (because it does not exist).  By differentiating between r-t-k and u-t-a, you can find where kernel pages exist, even if you cannot read them.  KAISER, and later KPTI, prevent this by causing all unnecessary kernel pages to be missing, so you cannot tell if the page is u-t-a because it never exists or if it is u-t-a because it exists only when the kernel is running.

The AMD claims that Meltdown do not apply to their CPUs appear to be specifically that AMD CPUs are immune to the new concept of divining memory contents by profiling the speculative execution.  The researchers allege, and I have not seen AMD deny, that AMD CPUs are still vulnerable to the weaker attack of KASLR bypass, since that only requires determining whether the page exists in the page table (as a hidden kernel-only page) versus does not exist at all.  KAISER was designed to stop that weaker attack, and KPTI, as a derivative of KAISER, stops KASLR bypass as a happy side effect.  Most people are focused on using KPTI to stop the far more severe (and allegedly Intel-only out-of-order-only) Meltdown attack.

----------

## pjp

@Hu:

Excellent, thank you!

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.

----------

## ian.au

Hu,

Thanks for taking the trouble to post one of the clearest summaries of those measures I've read.

----------

## PrSo

@Hu

IDKWTS, thank you very much.

----------

## mike155

Yesterday I posted performance measurement results and asked a question:

 *Quote:*   

> The test shows a performance degradation of nearly 30% (!) for Linux systems running in a QEMU VM. 
> 
> [...]
> 
> Does anyone have a clue, why the difference between pti and nopti is so much larger in a VM?
> ...

 

Good news: the performance degradation of nearly 30% I measured yesterday is - to a large extent - not a consequence of the Meltdown kernel patches, but a consequence of a missing CPU flag of my guest's CPU. During my tests yesterday, I started QEMU with the parameter "-cpu SandyBridge" and the guest's CPU did NOT have the CPU flag "pcid". Today I repeated the tests with QEMU parameter "-cpu SandyBridge,+pcid" and the guest's CPU had the CPU flag "pcid". Performance degradation between pti and nopti went down to (only) 9%.

```
Test: time emerge -B glibc >/dev/null

Yesterday's results (QEMU parameter: -cpu SandyBridge)

-------------------------------+---------------------+--------------+------

Kernel & config                | time [s]            | mean [s]     | rel.

of QEMU VM                     | (3 measurements)    |              | 

-------------------------------+---------------------+--------------+------

4.9.65 as of Nov. 2017         | 320.8, 320.9, 320.7 | 320.8 ± 0.1  | 100%

4.14.13, CONFIG_PTI=no,        | 324.2, 324.6, 325.0 | 324.2 ± 0.4  | 101%

4.14.13, CONFIG_PTI=yes, nopti | 327.2, 326.6, 325,3 | 327.2 ± 1.0  | 102%

4.14.13, CONFIG_PTI=yes, pti   | 411.7, 417.4, 412.7 | 411.7 ± 3.0  | 128%

-------------------------------+---------------------+--------------+------

Today's results (QEMU parameter: -cpu SandyBridge,+pcid)

-------------------------------+---------------------+--------------+------

Kernel & config                | time [s]            | mean [s]     | rel.

of QEMU VM                     | (3 measurements)    |              | 

-------------------------------+---------------------+--------------+------

4.14.13, CONFIG_PTI=yes, nopti | 322.1, 324.3, 323.0 | 323.1 ± 1.1  | 100%

4.14.13, CONFIG_PTI=yes, pti   | 349.1, 350.2, 350.9 | 350.1 ± 0.9  | 109%

-------------------------------+---------------------+--------------+------

Remarks:

- CONFIG_PTI: guest kernel configuration parameter 'CONFIG_PAGE_TABLE_ISOLATION'

- pti, npti: guest kernel command line parameter

- Host: Intel Xeon CPU E3-1245 V2, x86_64, 32GB Ram, Kernel 4.14.12, pti

- Qemu: 2.10.1-r1, virtio devices

- Guest: 2 Core x86_64, 4 GB RAM, /var/tmp is tmpfs 

```

Conclusion:

In order to avoid performance degradation in VMs due to Meltdown / Spectre patches, it is important that hypervisors enable the CPU flag "pcid" for guest CPUs if the flag is supported by the host's CPU. The same is probably true for the CPU flag "invpcid" (I can't test it, since I don't have a Haswell+ CPU).

----------

## eccerr0r

...which is unfortunate, my VM host is a Core2 Quad...

Need to test a 32-bit world in a container, to see if it's a viable option...

----------

## Aiken

 *mike155 wrote:*   

> 
> 
> In order to avoid performance degradation in VMs due to Meltdown / Spectre patches, it is important that hypervisors enable the CPU flag "pcid" for guest CPUs if the flag is supported by the host's CPU. The same is probably true for the CPU flag "invpcid" (I can't test it, since I don't have a Haswell+ CPU).

 

Which comes back to what I was thinking during my last post, the core2 will now have problems being a kvm host. I have been using -cpu host so my testing on an i7 already showed that instruction. My normal vm host is an i5 2500k which has pcid. This does not help the core2 which does not have that instruction. My last test on it was showing both cores up to 50% just in syscalls. For various values of bad I am hoping the i5 won't be too bad. I have given up on any idea for running kvm on the core2.

On the i7 set -cpu core2duo and my kernel compile test with pti=on, the time went from 22 - 23 seconds up to 24 - 34 seconds.

----------

## khayyam

WRT performance: retpoline fix supposedly solves performance hits for spectre.

best ... khay

----------

## EasterParade

Gotta make myself a sticky on desktop to pay attention to etc-update.

It wanted to overwrite /etc/grub.d/10_linux. The update would have removed 

```
if test -e "${dirname}/${i}" ; then

      initrd="early_ucode.cpio ${rel_dirname}/${i}"

      break

    else

      initrd="early_ucode.cpio"
```

----------

## Aiken

Wondering how many people are going to get caught out by the cpio archive being moved from /lib/firmware/microcode.cpio to /boot/intel-uc.img. Not a nice surprise turning on my pc and being greeted by grub complaining file not found. Thankfully a couple of headless boxes had not been rebooted yet.

----------

## luiztux

Here we go again. It seems that there is another security flaw with Intel firmwares.

https://arstechnica.com/information-technology/2018/01/researcher-finds-another-security-flaw-in-intel-management-firmware/

----------

## ian.au

 *luiztux wrote:*   

> Here we go again. It seems that there is another security flaw with Intel firmwares.
> 
> https://arstechnica.com/information-technology/2018/01/researcher-finds-another-security-flaw-in-intel-management-firmware/

 

That 'exploit' is neither new nor unique to intel, classic FUD

----------

## mno

Sorry for a potentially stupid question.  I run quite an old Intel Xeon 5500 arch, but run 'amd64' - most of the comments seem to be related to 'x86'.  It doesn't seem to make a difference whether I ran amd64 or x86 in this case, as long as it's an Intel CPU, correct?

----------

## eccerr0r

Indeed, doesn't matter if you're running 64 bit amd64 or 32 bit x86, both are affected.

There's a workaround for 64-bit amd64 for Intel CPUs problem with meltdown, but none for 32-bit at the moment, which is what the commotion is about.

----------

## mno

 *eccerr0r wrote:*   

> There's a workaround for 64-bit amd64 for Intel CPUs problem with meltdown, but none for 32-bit at the moment, which is what the commotion is about.

 

Thank you, if you can quickly dig this up, can you point me to the workaround?

----------

## eccerr0r

I guess this should be stickied somewhere but oh well, not a problem to keep posting it... 

https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre (oh wait, it's on the first post!)

----------

## mno

Thank you!  I did find that link going through this post, I wasn't sure if that's what you referred to by workaround for amd64 Intel.  Thanks again!

----------

## Hu

 *eccerr0r wrote:*   

> I guess this should be stickied somewhere but oh well, not a problem to keep posting it... 
> 
> https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre (oh wait, it's on the first post!)

 Several days ago, pjp put it in the first post of the thread.  Does that count?  :Smile: 

----------

## gengreen

I don't know how reliable is it, but I found it pratical to be informed about the meltdown/spectre security for my system : 

https://github.com/speed47/spectre-meltdown-checker

The script note :

 *Quote:*   

>  IMPORTANT:
> 
>  A false sense of security is worse than no security at all.

 

Loved it.

----------

## eccerr0r

 *Hu wrote:*   

> Several days ago, pjp put it in the first post of the thread.  Does that count? 

 

I'm just glad someone finally fixed the title correctly so that this bug didn't imply a denial of service vector versus a memory disclosure issue :p

----------

## PrSo

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

 

It does not matter if C_P_T_I is set YES or disabled.

Yesterday I have made some tests. I have compiled kernel with CONFIG_PAGE_TABLE_ISOLATION=YES but I havent observed anything in performance change. There is nothing about PTI in dmesg output. I have started to dig deeper:

From manual  *Documentation/x86/pti.txt wrote:*   

> It can be enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y

  the default PTI state during boot is set to "auto", and in 

```
arch/x86/mm/ptic.c
```

 there is a function:

```
 autosel:

   if (!boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN))

      return;

enable:

   setup_force_cpu_cap(X86_FEATURE_PTI);

}
```

With Thomas amendment AMD cpu's are exemplified from having X86_BUG_CPU_MELTDOWN flag on (previously was X86_BUG_CPU_INSECURE).

So it seems that even if you compile kernel with CONFIG_PAGE_TABLE_ISOLATION=Y PTI is auto-disabled on AMD cpu anyway.

----------

## dmpogo

In view of retpoline that supposedly has less performance hit than microcode update,   does it mean that one actually does NOT want to do microcode update for Spectra v2 mitigation ?

----------

## noci2

 *Ant P. wrote:*   

>  *PrSo wrote:*   This is another 3 in 1 meltdown-spectre mitigation checker:
> 
> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> 
> * Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 23 opcodes found, should be >= 70)
> ...

 

Same here:

--8<--

Will use vmlinux image /usr/src/linux/vmlinux

Will use kconfig /usr/src/linux/.config

Will use System.map file /boot/System.map-genkernel-x86_64-4.14.12-gentoo

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

* Checking count of LFENCE opcodes in kernel:  NO 

> STATUS:  VULNERABLE  (only 13 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

--8<--

----------

## blopsalot

 *gengreen wrote:*   

> I don't know how reliable is it, but I found it pratical to be informed about the meltdown/spectre security for my system : 
> 
> https://github.com/speed47/spectre-meltdown-checker
> 
> The script note :
> ...

 

A shell script checking kernel config is exactly that, a false sense of security. This project is the only PoC/test I found that's not garbage.

https://github.com/IAIK/meltdown

----------

## Naib

 *blopsalot wrote:*   

>  *gengreen wrote:*   I don't know how reliable is it, but I found it pratical to be informed about the meltdown/spectre security for my system : 
> 
> https://github.com/speed47/spectre-meltdown-checker
> 
> The script note :
> ...

 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

----------

## PrSo

 *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

 

100% agreed with that.

I have posted this only for reason to check if you have all AVAILIBLE mitigation applied in your kernel that are currently publicized (that are available in kernels provided by gentoo).

Same states the Disclamer.

To be sure that you are protected you have to test your system with proper PoC . There are many PoC's that doesnt work, or are giving false-positive. i.e.:

 *blopsalot wrote:*   

> https://github.com/IAIK/meltdown

 

gives me false-positive.

If that would be true the author of this script should get contacted with AMD or make a public statement about AMD's vulnerability to Meltdown (if this program test Meltdown case of course tough).

Post Sciptum:

I am not the author of this checker.

----------

## mike155

 *Quote:*   

> Part of me groaned when that "checker" was being used around this place

 

 *Quote:*   

> A shell script checking kernel config is exactly that, a false sense of security.

 

I like this checker script - and I'm glad it exists! Of course, it cannot prove that your computer is secure. But it can show which patches have been installed and what's left to be done. What's wrong with that?

----------

## blopsalot

 *PrSo 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 
> 
> 100% agreed with that.
> ...

 

I've tested it thoroughly. It's working code. You are just used to the false-negatives at this point.

edit: I guess I'll add, that it does not do it for you. running ./test is not verification.

----------

## eccerr0r

Will definitely emphasize one of the spectre PoC code will remain test positive even with all the patches applied (unless you recompile with a patched gcc, which then would end up being a false negative.)  That spectre PoC is only good for demonstrating the CPU has the issue, but does not prove your computer is secure or not.

----------

## figueroa

I updated my kernel to the 4.9.76-gentoo ~amd64 and don't think I can do more. There doesn't appear to be fixed microcode yet for my Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (Intel calls it "Products formerly Sandy Bridge" from 5-6 years ago).

Good news is that the kernel seems to run just fine.

----------

## PrSo

 *blopsalot wrote:*   

> 
> 
> I've tested it thoroughly. It's working code. You are just used to the false-negatives at this point.
> 
> edit: I guess I'll add, that it does not do it for you. running ./test is not verification.

 

Maybe not exact false-positive.

I have repeated the test, but after executing 

```
sudo taskset 0x1 ./kaslr
```

 it took about 20 minutes to guess the address. (one cpu core was 100% utilized), 

and then 

```
sudo taskset 0x1 ./reliability ....
```

 is running now almost an hour or so. These are not couple of seconds mentioned on the web page.

This machine has an old apu a6 6310.

----------

## blopsalot

when you are using a race condition to launch a microarchitectural attack there will be some inconsistency.  :Wink: 

----------

## The Main Man

PoC that needs root privileges to work, I don't get that   :Confused: 

----------

## blopsalot

 *kajzer wrote:*   

> PoC that needs root privileges to work, I don't get that  

 

u can't just give it away to the scriptkidz

----------

## The Main Man

 *blopsalot wrote:*   

>  *kajzer wrote:*   PoC that needs root privileges to work, I don't get that   
> 
> u can't just give it away to the scriptkidz

 

But there already are PoC's that work without root access, I can only imagine what is out there in the wild, so I'm pretty sure they can get that easily.

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.

----------

## blopsalot

 *kajzer wrote:*   

>  *blopsalot wrote:*    *kajzer wrote:*   PoC that needs root privileges to work, I don't get that   
> 
> u can't just give it away to the scriptkidz 
> 
> But there already are PoC's that work without root access, I can only imagine what is out there in the wild, so I'm pretty sure they can get that easily.
> ...

 

had u actually read the documentation, it is explained. they chose not to include a mechanism to defeat KASLR without root. physical_reader and memdump run from userspace.

----------

## pjp

 *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): 

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

----------

## pjp

 *Naib wrote:*   

>  *blopsalot wrote:*   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?

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

----------

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

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

----------

## Naib

That's because there are two variants of spectre

----------

## mv

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

----------

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

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

 

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

----------

## tholin

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

----------

## blopsalot

 *pjp wrote:*   

>  *Naib wrote:*    *blopsalot wrote:*   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?
> ...

 

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  :Smile: 

There are two kernel .config options:

```
CONFIG_RETPOLINE=y

CONFIG_PAGE_TABLE_ISOLATION=y
```

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

```
pti=<value>

nopti

spectre_v2=<value>

nospectre_v2

```

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

```
/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):

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

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

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

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

----------

## mike155

 *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!  :Sad: 

----------

## mike155

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

 

----------

## mv

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

----------

## Hossie

 *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?   :Shocked: 

----------

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

 *NeddySeagoon wrote:*   

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

 why not? you have been running a 9999 CPU for the last couple of decades   :Twisted Evil: 

----------

## 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.  :Very Happy: 

----------

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

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

----------

## mno

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

----------

## ian.au

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

----------

## Naib

 *pjp wrote:*   

> Intel Warns Its Patches for Chip Flaws Are Buggy  *paywall wrote:*   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

 *krinn wrote:*   

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

 

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

----------

## mike155

 *krinn wrote:*   

> - 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   :Laughing:   :Rolling Eyes:   :Sad: 

----------

## krinn

 *Naib wrote:*   

> 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

 *krinn wrote:*   

> 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

 *mv wrote:*   

>  *krinn wrote:*   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-security-issue-update-addressing-reboot-issues/

Looks like i forget broadwell with haswell.

----------

## mno

More broad article on the microcode side of things:

https://arstechnica.com/gadgets/2018/01/spectre-and-meltdown-patches-causing-trouble-as-realistic-attacks-get-closer/

----------

## kavra

 *mv wrote:*   

>  *krinn wrote:*   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

 *mno wrote:*   

> More broad article on the microcode side of things:
> 
> https://arstechnica.com/gadgets/2018/01/spectre-and-meltdown-patches-causing-trouble-as-realistic-attacks-get-closer/

 

 *https://arstechnica.com/gadgets/2018/01/spectre-and-meltdown-patches-causing-trouble-as-realistic-attacks-get-closer wrote:*   

> 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

 *https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/ wrote:*   

> 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

 *PrSo wrote:*   

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

 

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

 *Spargeltarzan wrote:*   

> 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-01/msg01303.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.3.0-RC-20180117/

----------

## mike155

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

```
# 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!  :Smile:  Much better than my last result.

----------

## Thistled

 *VinzC wrote:*   

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

https://newsroom.intel.com/news-releases/security-first-pledge/

 *Quote:*   

> 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.   :Very Happy: 

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

 *Hossie wrote:*   

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

```
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  :Very Happy: 

----------

## eccerr0r

 *Ska` wrote:*   

> 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

----------

## NeddySeagoon

eccerr0r,

So I can steal your data when the machine is air gapped and phone home with it when it has a network connection?

----------

## eccerr0r

Well, no, the assumption is that prior to emerge -e @world it hasn't been compromised, so running emerge -e @world with the unsafe kernel is still secure (emerge requires root permissions anyway), and after that, the system should remain secure.  Not sure where it's unsafe unless you get in before the world emerge; in that case one is already screwed and has nothing to do with temporarily running an insecure kernel to build world as fast as possible.

----------

## PrSo

 *Hossie wrote:*   

> 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 the same way as Ska, that for Spectre v1 recompilig kernel would be enough.

 *Dan Williams wrote:*   

> Note that the BPF fix for Spectre variant1 is merged for 4.15-rc8.

 

source: https://lwn.net/Articles/744752/

But "prevent bounds-check bypass via speculative execution" has not been mainlined yet thoug.

----------

## Spargeltarzan

Does somebody know how it is possible that RHEL/CentOS updated/mitigated Spectre v1? 

I thought even that reptoline topic is only coming with the new gcc for Spectre v2 and v1 is not resolved/mitigated yet?...

----------

## NeddySeagoon

Spargeltarzan,

Maybe they haven't?

Perhaps it was only partial mitigation before the problem was fully understood.

A false sense of security is worse than no security at all. :)

----------

## pjp

RHEL lists the overall state as "ongoing," so I don't think it is considered resolved.

https://access.redhat.com/security/vulnerabilities/speculativeexecution

----------

## The_Great_Sephiroth

Lots of good info here, but I have a question. I have read lots of information on this bug lately and everything I read claims that ARM, Intel, and AMD are affected by this bug, but from what I read here, while a tad dated, AMD is not affected. Why are the big IT sources claiming they are? Is it just fewer CPUs?

I have an old Gateway G6-233 with a P2/233MHz slot1 chip in it. Runs 98SE for old games. Wonder if it will be patched...   ;P

----------

## NeddySeagoon

The_Great_Sephiroth,

Heres what AMD say.

Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors. 

Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.

... While we believe that AMD’s processor architectures make it difficult to exploit Variant 2 ...

Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors. 

So that's a definite maybe from AMD

----------

## Tony0945

IIRC, Amd is immune to Meltdown but not Spectre. I really don't know about ARM. Having received a Raspberry Pi for Christmas, I'd really like to know.

----------

## Spargeltarzan

NeddySeagoon,

This page made me believe RHEL has something

But I see this test result might be wrong positive...

----------

## Naib

 *Tony0945 wrote:*   

> IIRC, Amd is immune to Meltdown but not Spectre. I really don't know about ARM. Having received a Raspberry Pi for Christmas, I'd really like to know.

 Spectre no, meltdown no.

Meltdown was Intel screwing up. Spectre makes use of a computer science concept that didn't consider rogue training... ANYTHING that uses speculative branching is at risk

Intel, AMD, GPU's from Nvidia, IBM power series, some ARM cores.

The RPi however isn't because the arm-core it is using doesn't make use of speculative branching https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

----------

## nivedita

 *Naib wrote:*   

>  *krinn wrote:*   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)
> ...

 

They had a blog post about it on the same day as that wsj article, and the buggy microcode is not available from intel in the first place -- not sure if it ever was, gentoo was hosting it separately. It was just a clickbait article from the wsj.

----------

## bunder

 *nivedita wrote:*   

> They had a blog post about it on the same day as that wsj article, and the buggy microcode is not available from intel in the first place -- not sure if it ever was, gentoo was hosting it separately. It was just a clickbait article from the wsj.

 

gentoo gets the microcode updates direct from intel.

```
SRC_URI="http://downloadmirror.intel.com/${NUM}/eng/microcode-${PV}.tgz"
```

----------

## Tony0945

 *Naib wrote:*   

> The RPi however isn't because the arm-core it is using doesn't make use of speculative branching https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

   Thanks!

----------

## mahdi1234

From Greg's blog http://kroah.com/log/blog/2018/01/19/meltdown-status-2/ ...

###############

Is my machine vulnerable?

For this question, it’s now a very simple answer, you can check it yourself.

Just run the following command at a terminal window to determine what the state of your machine is:

```
$ grep . /sys/devices/system/cpu/vulnerabilities/*

```

On my laptop, right now, this shows:

```
$ 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:Vulnerable: Minimal generic SM retpoline

```

This shows that my kernel is properly mitigating the Meltdown problem by implementing PTI (Page Table Isolation), and that my system is still vulnerable to the Spectre variant 1, but is trying really hard to resolve the variant 2, but is not quite there (because I did not build my kernel with a compiler to properly support the retpoline feature).

If your kernel does not have that sysfs directory or files, then obviously there is a problem and you need to upgrade your kernel!

###############

just fyi this directory comes with gentoo-sources 4.14.14 ...

----------

## Hossie

 *Spargeltarzan wrote:*   

> Does somebody know how it is possible that RHEL/CentOS updated/mitigated Spectre v1? 
> 
> I thought even that reptoline topic is only coming with the new gcc for Spectre v2 and v1 is not resolved/mitigated yet?...

 

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

* Checking count of LFENCE opcodes in kernel:  YES 

> STATUS:  NOT VULNERABLE  (106 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

uname -r

3.10.0-693.11.6.el7.x86_64

```

Somehow they still fixed it  :Razz: 

----------

## Hossie

Btw any news about new QEMU releases to SPEC_CTRL CPUID into VMs?

----------

## roki942

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf

----------

## PrSo

Intel is still working on resolving problems with the new microcode mitigations:

https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners

----------

## The_Great_Sephiroth

I checked my Core2Duo laptop and it claims that it has no bugs. This is via cpuinfo. Strange. I'll check via the method in the post a few above this one when I get back to my laptop later today.

I am curious though. This dates all the way back to the Windows 95 era and Pentium CPUs. Was this just a design flaw that was never even considered back then? I don't understand how this can go so far back and never have been discovered. I guess I cannot wrap my mind around it all, but my current thought is that this was like lead being added to gasoline. It made soft valves last forever, but we had no idea we were killing ourselves with it.

*UPDATE*

I do not have all that stuff, but I am running the stable kernel, 4.9.76 I believe.

```

9y84mj1 ~ # grep . /sys/devices/system/cpu/

cpu0/       cpuidle/    kernel_max  offline     power/

cpu1/       hotplug/    microcode/  online      present

cpufreq/    isolated    modalias    possible    uevent

9y84mj1 ~ # uname -r

4.9.76-gentoo-r1

```

----------

## eccerr0r

Core2 Duos are affected, everything from the ppro onwards are affected except itanium and only the in-order atoms (the newer atoms are affected.)

I think it was simply an oversight but there are plenty of conspiracy theories out there.

----------

## The_Great_Sephiroth

I assumed mine was affected, but  why don't I have the info which should tell me so like you do? Is it simply because I am running an older laptop?

----------

## eccerr0r

Exactly.

The PoC are earlier on this thread but need to be modified to run on the older chips.  I was able determine that my Core2 Duo and Core2 Quad are affected by at least Spectre, but the PoC run so poorly that it was successful 15% of the time. 

However if it was able to get it 15% of the time, it means that a determined hacker is still able to get the information, just takes longer.

----------

## Pearlseattle

Fyi:

"x11-drivers/nvidia-drivers-340.106" is now available as well in the portage tree => fix for old GPUs (in my case my passively-cooled GT218 / GeForce 210) which includes Page Table Isolation patches (info source here).

Edit:

here updated infos for all other nVidia GPUs.

----------

## Hu

 *The_Great_Sephiroth wrote:*   

> I assumed mine was affected, but  why don't I have the info which should tell me so like you do? Is it simply because I am running an older laptop?

 If you mean, "Why are the sysfs virtual files missing?", I think the answer is that your kernel is too old.  These virtual files were added to stable in sysfs/cpu: Add vulnerability folder, also known as v4.9.76-73-g11ec2df9c020.  Therefore, your v4.9.76-0 is 73 commits too old to have them.  Upgrade to a later v4.9.x (preferably the latest v4.9.x).

As for how this persisted for two decades, I attribute it to a lack of imagination.  The CPU does all the things it is designed and documented to do (at least in this area).  This is not an errata.  It is a design flaw that can be leveraged by malicious code to do bad things.  The designers seemingly never contemplated that abusing microarchitectural quirks was a viable way of attacking the system.

----------

## blopsalot

see below.Last edited by blopsalot on Fri Jan 26, 2018 1:32 pm; edited 1 time in total

----------

## Tony0945

 *Hu wrote:*   

> The designers seemingly never contemplated that abusing microarchitectural quirks was a viable way of attacking the system.

 

Reminds me of the phone phreaker "Captain Crunch" back in the day. The story is that he was eating breakfast and  the box of Captain Crunch cereal had a toy whistle as a prize (cereal used to have prizes to entice kids to bug their moms to buy it). He blew the whistle into a phone and found it opened an unregistered trunk line. Now who would think to do that?  

AT&T (then a monopoly) paid the cereal company (Kellog?) to redesign the whistle and bought up all the existing boxes, many millions of dollars.

----------

## krinn

 *Tony0945 wrote:*   

>  *Hu wrote:*   The designers seemingly never contemplated that abusing microarchitectural quirks was a viable way of attacking the system. 
> 
> Reminds me of the phone phreaker "Captain Crunch" back in the day. The story is that he was eating breakfast and  the box of Captain Crunch cereal had a toy whistle as a prize (cereal used to have prizes to entice kids to bug their moms to buy it). He blew the whistle into a phone and found it opened an unregistered trunk line. Now who would think to do that?  
> 
> AT&T (then a monopoly) paid the cereal company (Kellog?) to redesign the whistle and bought up all the existing boxes, many millions of dollars.

 

Money is the key in our world, to a point, that even if designers see a problem and report it: the issue will be balance against money gain ; and if product expected sells > money invest to fix the already known issue -> sell it.

Look at wolswagen, they aren't doing what they can to not pay any fee for the cheating program in their engines: they are doing what they can to pay the fee they have estimate they will be force to pay + estimate cost to fix cars affected. And that money is already in some account (doing even more money while they were waiting someone to caught them).

Because even AT&T appears like looser paying millions dollars to Kellog for a whistle, they were able to spend that much money because their pockets were full.

That's politic of systemd: who gives a fuck if systemd will be good or bad at Redhat? Redhat just need everyone to depends on them, systemd could be swap with anything they wish once your systems are tied to Redhat and they own all the market share. They don't need everyone using systemd, they need everyone linux to be Redhat, and if systemd is a failure, they will fix it or create a new product ; but you will be force to use that new product.

And if users/customers are force to pay for the new product, oh dude, you're a terrible financial genius!

People have pay your dirty product and will happily or not pay again to have functional one

Everyone point Intel, but the security issue is in all "modern" cpu, which will lead to "our products sucks, but not just us, and even AMD could claim meltdown is not an issue, spectre1 still hit them like us, and the cpu are not truly fixable, here are new cpu that aren't affected at all: no PTI, no hack, no microcode need: just some little more money from you buying them".

Because old product sells are expect to get down, little investors are scared and Intel is loosing them, but big investors that could afford to wait, are expecting Intel to get a new cpu all fixed (and this one out faster than concurrent because Intel is sleeping on a big money bed and could afford to spent some to faster research), and once that product is out: huge money coming in, what cpu will you buy if all cpu are "defective" but not the new cpu Intel has just release?

The best thing big investors in Intel or AMD company should do is investing few bucks in building spectre1 viruses that could be release once fixed design cpu are out to even get more crash return faster...

Face it guys, we do whatever we can to fix that: using PTI, waiting like crazy patches for gcc... But first they only "mitigate" the issue and not fix it, and second, if i were a "bad guy" doing virus, i would be coding a spectre1 one...

To me the future is all clear: spectre1 virus everywhere, and fixed cpu out top sells. If we trust the guys that found the issues, first fixed cpu out will take some time, but in mean time i think cpu maker will be able to get out "crappy" fixed cpus: cpu not affect by that because they lack speculation or cache or whatever, so running crappy but 100% safe ; which will be of value for many : think, do you prefer a kick ass cpu running fast for your server but everyone could hack them, or a slower one, but totally safe?

Which is even better for their pockets: you reuse a design you know but cut it to avoid the bugs, you have sold millions of affected cpu, you will sold millions of crappy fixed ones, and will later then sold millions of brand new one that run fast and are secure.

For one task your customer might brought 3 cpu (the "old" one, the crappy/slow fixed one, and the fixed fast one) instead of just one, awesome!

Even if customer will wait for fixed cpu (or no crappy fixed one appears in between), the second market will be killed for a while, and that second hand cpu is worth 0 for cpu maker, they have sold the unit, and anyone reselling it later will gave 0 money in their pocket, but if all second hand cpu are flaw, the second hand market will be fucked for some time, meaning sells of cpu will only be new cpu ones for some time, and on those sells, they do take the money.

Even Apple good plan to slow down cpu of older products is no more need: no need to slow down the iphone X, just build an iphone X+1 with a fixed cpu and users will rush to it.

To me that spectre/meldown is a total kick ass news for cpu maker, and good days are coming for them  :Smile: 

----------

## eccerr0r

Hooray more planned/forced obsolescence! *sigh*

----------

## 1clue

 *Tony0945 wrote:*   

>  *Hu wrote:*   The designers seemingly never contemplated that abusing microarchitectural quirks was a viable way of attacking the system. 
> 
> Reminds me of the phone phreaker "Captain Crunch" back in the day. The story is that he was eating breakfast and  the box of Captain Crunch cereal had a toy whistle as a prize (cereal used to have prizes to entice kids to bug their moms to buy it). He blew the whistle into a phone and found it opened an unregistered trunk line. Now who would think to do that?  
> 
> AT&T (then a monopoly) paid the cereal company (Kellog?) to redesign the whistle and bought up all the existing boxes, many millions of dollars.

 

How would you know, without prior knowledge? Assuming you opened the trunk line, how could you tell? What could you do with it, unless you had all the gear sitting there to take advantage?

----------

## Aiken

 *eccerr0r wrote:*   

> Exactly.
> 
> The PoC are earlier on this thread but need to be modified to run on the older chips.  I was able determine that my Core2 Duo and Core2 Quad are affected by at least Spectre, but the PoC run so poorly that it was successful 15% of the time. 
> 
> However if it was able to get it 15% of the time, it means that a determined hacker is still able to get the information, just takes longer.

 

The Am-I-affected-by-Meltdown checker which seems to do an actual check instead of looking for the pti flag shows my core2 duo as affected by metldown. The only machine I have not been able to get a positive result on is the p4 and that may be a timing issue like getting the spectre poc working on older processors. I have 1 c2d with 4.14.15 and another with 4.9.78. If I cat /sys/devices/system/cpu/vulnerabilities/* both are now showing

Mitigation: PTI

Vulnerable

Vulnerable: Minimal generic ASM retpoline

If I boot with pti=pff they both show

Vulnerable

Vulnerable

Vulnerable: Minimal generic ASM retpolin

----------

## mike155

GCC 7.3 was released a couple of hours ago:

 *Richard Biener wrote:*   

> The GNU Compiler Collection version 7.3 has been released.
> 
> GCC 7.3 is a bug-fix release from the GCC 7 branch
> 
> containing important fixes for regressions and serious bugs in
> ...

 

See: https://gcc.gnu.org/ml/gcc-announce/2018/msg00000.htmlLast edited by mike155 on Thu Jan 25, 2018 2:14 pm; edited 1 time in total

----------

## blopsalot

see belowLast edited by blopsalot on Fri Jan 26, 2018 1:32 pm; edited 1 time in total

----------

## rburcham

Should we expect to see the gcc and binutils updates in portage as ~arch here pretty soon?

----------

## Zentoo

 *krinn wrote:*   

>  *Tony0945 wrote:*    *Hu wrote:*   The designers seemingly never contemplated that abusing microarchitectural quirks was a viable way of attacking the system. 
> 
> Reminds me of the phone phreaker "Captain Crunch" back in the day. The story is that he was eating breakfast and  the box of Captain Crunch cereal had a toy whistle as a prize (cereal used to have prizes to entice kids to bug their moms to buy it). He blew the whistle into a phone and found it opened an unregistered trunk line. Now who would think to do that?  
> 
> AT&T (then a monopoly) paid the cereal company (Kellog?) to redesign the whistle and bought up all the existing boxes, many millions of dollars. 
> ...

 

Hey dude ! You make my day ! It's accuratelly that I think... Big money pocket always find a way to make their pockets bigger !

Even after that everyone knows that Intel CEO have sold all his company shares on the stock market before the Meltdown NDA and even after Intel have just diluated their responsabilities about Meltdown by creating the confusion with Spectre problem (telling to the world that they was not alone to be affected: other cpu sellers like AMD, IBM, ARM are impacted too), no one take care about how goes the business behind....

To sum up, Meltdown is an Intel flaw while Spectre is a a flaw by design (Tomasulo algorithm) implemented in almost all modern processors.

Everyone are thinking now it's the same problem but it's not. Really good communication strategy from Intel.

And for sure we will all of us buy a fixed cpu the day we can !

The most interesting part is coming: how they could sell us new fixed cpu with less performance since I can't see how they can create more powerfull CPU easily.

Adding more CPU cache could be the key but actual problems are related to CPU cache so it's a no go. And since they will hit the lowest thickness manufacturing process, there is no so much room to go ahead on performance. The only way that I can see is parallelism (so more core) because AMD force them to open this path with their last architecture....

So wait and see.... but stay aware in which pocket your money will go !

----------

## blopsalot

updatedLast edited by blopsalot on Sun Jan 28, 2018 2:05 am; edited 1 time in total

----------

## mv

 *blopsalot wrote:*   

> add "-mindirect-branch=thunk" to your CFLAGS

 

I am again somewhat confused: The kernel adds -mindirect-branch=thunk-extern. Is this meant only for the kernel or is it better/worse?

Also AFAIK the kernel uses -mindirect-branch-register. Sounds like it might be quicker. Shouldn't one activate it?

And why does nobody seem to use -mfunction-return? Is it not necessary? (And if it is useful: Is the value thunk-inline or thunk-extern preferrable?)

Moreover, what is the connection of all these flags with new binutils? Won't they work without it?

----------

## blopsalot

i am still trying to catch up too, so please correct any mistakes i make.  :Smile:  my understanding is that the mindirect-branch can go different ways, using updated microcode or if not available, comparable assembly. the kernel is already configured to set compiler options appropriately automatically, it is my understanding only mindirect-branch=thunk is needed universally, but i might be wrong. binutils must be updated so it knows what to do with new code, I can't find mailing list post atm.

edit:

 *Quote:*   

> Add -mindirect-branch= option to convert indirect call and jump to call
> 
> and return thunks.  The default is 'keep', which keeps indirect call and
> 
> jump unmodified.  'thunk' converts indirect call and jump to call and
> ...

 

https://sourceware.org/ml/binutils/2018-01/msg00030.htmlLast edited by blopsalot on Fri Jan 26, 2018 10:59 pm; edited 1 time in total

----------

## mv

 *blopsalot wrote:*   

> https://sourceware.org/ml/binutils/2018-01/msg00030.html

 

This looks like it is a mitigation technique for libraries which is independent of the gcc compiler options. But I might be wrong.

----------

## mike155

 *blopsalot wrote:*   

> add "-mindirect-branch=thunk" to your CFLAGS

 

I got the result I posted here ('Mitigation: Full generic retpoline') with vanilla GCC 7.3.0RC1 and vanilla Linux kernel 4.14.14, but WITHOUT adding anything to CFLAGS and WITHOUT updating binutils. 

The Linux kernel build system knows which options it has to pass to GCC. Look at /usr/src/linux/arch/x86/Makefile, line 239:

```
# Avoid indirect branches in kernel to deal with Spectre

ifdef CONFIG_RETPOLINE

    RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern -mindirect-branch-register)

    ifneq ($(RETPOLINE_CFLAGS),)

        KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE

    endif

endif

```

----------

## blopsalot

 *mv wrote:*   

>  *blopsalot wrote:*   https://sourceware.org/ml/binutils/2018-01/msg00030.html 
> 
> This looks like it is a mitigation technique for libraries which is independent of the gcc compiler options. But I might be wrong.

 

i guess my edit implied they were related? no i was just seeing if it worked in as many places as possible. i ended up editing the eclass. 

my point was binutils needs updated as well if you want to harden your toolchain.

 *mike155 wrote:*   

>  *blopsalot wrote:*   add "-mindirect-branch=thunk" to your CFLAGS 
> 
> I got the result I posted here ('Mitigation: Full generic retpoline') with vanilla GCC 7.3.0RC1 and vanilla Linux kernel 4.14.14, but WITHOUT adding anything to CFLAGS and WITHOUT updating binutils. 
> 
> The Linux kernel build system knows which options it has to pass to GCC. Look at /usr/src/linux/arch/x86/Makefile, line 239:
> ...

 

yeah i said that lol

edit:

the conclusion I have come to is that you use -mindirect-branch=thunk-extern -mindirect-branch-register if your processor got a microcode update. -mindirect-branch=thunk if not. -mindirect-branch=thunk is safe(ish)(my world sets are not that big) to apply globally, ignoring performance impact

heres what i was referring to:

 *Quote:*   

> What you should know?
> 
> > --------------------------------
> 
> >
> ...

 

----------

## mv

 *mike155 wrote:*   

> Full generic retpoline') with vanilla GCC 7.3.0RC1 and vanilla Linux kernel 4.14.14

 

This might be true for the kernel, but my question is more related to mitigating spectre for other applications.

----------

## mv

 *blopsalot wrote:*   

> the conclusion I have come to is that you use -mindirect-branch=thunk-extern -mindirect-branch-register if your processor got a microcode update.

 

The description does not indicate this. From the description of -mindirect-branch it sounds more like thunk-extern is appropriate for the kernel while thunk is appropriate for "ordinary" linking (as in userspace). But actually the description is so vague that it is impossible to understand what is meant. That's why I asked here...

----------

## blopsalot

 *mv wrote:*   

>  *blopsalot wrote:*   the conclusion I have come to is that you use -mindirect-branch=thunk-extern -mindirect-branch-register if your processor got a microcode update. 
> 
> The description does not indicate this. From the description of -mindirect-branch it sounds more like thunk-extern is appropriate for the kernel while thunk is appropriate for "ordinary" linking (as in userspace). But actually the description is so vague that it is impossible to understand what is meant. That's why I asked here...

 

at least llvm made it easy to understand lol. 

edits:

tldr:

thunk is the original google implementation, but after realizing it didn't work in kernel  --- variant 1

https://support.google.com/faqs/answer/7625886

they needed another version: thunk-extern --- variant 2

https://lwn.net/Articles/742756/

thunk-inline is a gcc rendition to inline the code in their asm, IT IS compatible with -mcmodel=large. 

https://patchwork.ozlabs.org/patch/856627/

https://github.com/gentoo/gentoo/commit/f59c667e9c206e59fea9f13f47eac488822ebba2

binutils better explanation on PLT speculative execution barriers --- another variant 2 (sorry for confusion, amd64 was NOT patched besides readelf and objdump, so looks like it only contains variant 2 "fix" for powerpc and powerpc64

https://sourceware.org/ml/binutils/2018-01/msg00290.html

https://sourceware.org/ml/binutils/2018-01/msg00134.html

-mindirect-branch=thunk is the right choice to enable globally. kernel will use what its supposed to automagically.

the processors are broke, retpoline is duck tape. lol

----------

## mv

So let me summarize my current understanding.

Every claim in this list is to be understood as a question whether I understood correctly...

thunk-extern is needed only for the kernel or kernel modules; everything else should use thunk.Only if -mcmodel=large is needed one should fallback to thunk-internal because it is the slowest or most memory-expensive variant.-mindirect-branch=... is needed for practically every x86/amd64 processor. On llvm one should use -mretpoline instead-mfunction-return=... is needed only on Intel I3-6???* and newer processorsllvm currently does not have the additional protection against the return prediction variant of spectre provided by -mfunction-return=...

-Wl,-z,retpolineplt is not needed at all on amd64/x86 architecture-mindirect-branch-register is either

(a) an additional protection for some processors for which certain register jumps can be exploited (i.e. it uses the -mindirect-branch=... mechanism also in these cases) or

(b) it is a different implementation of -mindirect-branch=... which uses a register which might be slower or faster than the original implementation.The microcode update is something independent which is not needed for any of the flags: The retpoline mechanism is superior to using an extra command which was intel's oiriginal suggestionIn particular, I would be interested in case (a) of -mindirect-branch-register for which processors this is needed and whether it is provided by llvm.

Also, I am curious why the kernel is not using -mfunction-return=thunk-extern, at least optionally.

----------

## blopsalot

1. I have only tested thunk, it seems stable so far on amd64 glibc and uclibc.

2. That is the question.  :Smile: 

3. I would assume all processors with similar branch prediction are even though it will not be admitted until proven. powerpc and powerpc64 for sure. arm has admitted some chips are. 

4. i have not messed with it yet, it looks like it though. Theres also -mindirect-branch-loop

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00423.html

https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/config/i386/i386.c

```
else

   cfun->machine->function_return_type = ix86_function_return;

      /* -mcmodel=large is not compatible with -mfunction-return=thunk

    nor -mfunction-return=thunk-extern.  */

      if ((ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC)

     && ((cfun->machine->function_return_type

          == indirect_branch_thunk_extern)

         || (cfun->machine->function_return_type

        == indirect_branch_thunk)))

   error ("%<-mfunction-return=%s%> and %<-mcmodel=large%> are not "

          "compatible",

          ((cfun->machine->function_return_type

       == indirect_branch_thunk_extern)

      ? "thunk-extern" : "thunk"));

    }
```

5. I mislabeled as variant 1. variant 1 is the inherent hardware flaw

6. The patch was withheld for now to those targets, it is however the only variant 2 ppc and ppc64 fix now that I know of and is in 2.30. They are rapidly stabilizing 2.30

7. it's one of the tricks the kernel does  :Smile: 

https://patchwork.ozlabs.org/patch/859912/

8. My testing machine is a westmere xeon, I will test more on that soon. I would think you use -mfunction-return -mindirect-branch-loop based on the naming "cfun->machine->function_return_type = ix86_function_return;" from above, maybe someone else knows?

They are both kernel specific as far as I know, but I am sure there will be other uses, cannot remember details atm, but it has to do with the protected memory. Not sure about llvm kernel compiling, I would think it's gcc only for now, but they do not take long. This is a good write up though.

https://reviews.llvm.org/rLLD323155Last edited by blopsalot on Sun Jan 28, 2018 9:36 pm; edited 1 time in total

----------

## tholin

 *mv wrote:*   

> The microcode update is something independent which is not needed for any of the flags: The retpoline mechanism is superior to using an extra command which was intel's oiriginal suggestion

 

These compiler switches are only related retpolines but my understanding is that even if the entire system is compiled with retpolines the microcode fix is still needed. The kernel need some way to flush the branch predictor before calls to UEFI runtime services because the UEFI is not compiled with retpolines. Transitions to system management mode also needs to be protected and the new microcode do that automatically without operating system involvement.

An idea I saw somewhere was to add a bit the ELF headers so programs can tell the kernel they have been compiled with retpolines. That way the kernel don't have flush the branch predictor when context switching to such a program. The kernel and toolchain people are still weighing their options.

----------

## alex-kas

Hi folks,

I'm totally confused, my brain is exploding.

Can anyone explain me why should someone think about recompiling something more than a kernel??? I mean to defend from Specter. I was thinking that having kernel compiled with the retpoline switches I kinda guarantee this kernel will help me protecting my box. Am I wrong?

Reading previous posts in this and other threads I got that people want other stuff to be recompiled. Why? Do you want to say that even if the kernel is done right some program may still penetrate inside because this program itself has not been retpoline-d? But than what the point in all of that? I think I'm kinda sure that standard packages are not intended to steal my data. I want to be protected from something of the totally third-party staff, which I had no control at all during the stage of its construction/compiling/linking/etc. Isn't this the point of defense???

Also, as tholin wrote in the previous post, devs try or at least think to implement ELF changes which would be used by the kernel in order to speedup things IF the program with such an ELF has a bit indicating the retpoline protection switches were used. Is it a joke? I will compile my binary my way and then put whatever bit you want  :Smile:  And the kernel would blindly think it is a wise and proper app???

So, back to the question: what is the background for aiming to the whole box re-compilation? And, if yes, how to do the same with external/binary packages??? And if yes, recompile and yes, no control of binary packages then how to protect if these are malicious intruders???

Being driven nuts

----------

## NeddySeagoon

alex-kas,

Do you believe the kernel ?

```
cat /sys/devices/system/cpu/vulnerabilities/*

Not affected

Vulnerable

Vulnerable: Minimal AMD ASM retpoline
```

Thats on 

```
uname -a

Linux NeddySeagoon_Static 4.15.0-rc8 #1 SMP PREEMPT Mon Jan 15 15:49:15 GMT 2018 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux
```

 built with gcc-7.2.0-r1.

I'll test with gcc-7.3 later.

----------

## The Main Man

But that doesn't make sense (the need to compile everything with repto and only then you're safe), ok here in gentoo we do that from time to time for various reasons, so no big deal, but how would that work in binary distributions, what about packages coming from ppa's or other non-distro sources, not to mention other OS's like Windows, how's that gonna work ...

----------

## alex-kas

+1 to Kajzer,

How binary packages can be controlled?

To NeddySeagoon:

I believe too few species in this world and trust ..., sometimes do not trust even to myself ...

Compiling kernel with gcc 7.3.0 produces to me on kernel-4.14.15:

```

cat /sys/devices/system/cpu/vulnerabilities/* 

Mitigation: PTI

Vulnerable

Mitigation: Full generic retpoline

```

And I for sure have not recompiled anything else yet.

I can imagine that generically any kind of a kernel or a hypervisor may do a better job having retpoline protection in it. I thus can imagine that kernel is what awaits for retpoline to protect us in the userland. On the same ground firefox maybe can become safer for running javascripts if the firefox itself has some setting for -mindirect-branch during the emerge ... The same for virtualbox and similar stuff.

The last proposition is however a conjecture. What do you guys think about all of that?

----------

## PrSo

I agree with kajzer.

Previously, at time when I wrote post about compiling everything (@world) with retpoline there was a discussion among kernel people how to resolve mitigation for Spectre. 

Since AMD's KVM and Intel's VT are vulnerable to Spectre v2 counter action should be done by authors of VM's, ie. Qemu:

https://www.qemu.org/2018/01/04/spectre/

With mitigation applied to kernel host machines should be safe.

Same regards to web browsers. Firefox applied own patches, and so Chrome. Qtwebengine would have mitigation from version 5.9.4 applied:

https://codereview.qt-project.org/#/c/216729/

https://bugreports.qt.io/browse/QTBUG-65561

To conclude IMHO kernel should be enough but also needed to be supported by patches to critical applications.

----------

## tholin

 *alex-kas wrote:*   

> Can anyone explain me why should someone think about recompiling something more than a kernel??? I mean to defend from Specter. I was thinking that having kernel compiled with the retpoline switches I kinda guarantee this kernel will help me protecting my box. Am I wrong?
> 
> 

 

Compiling the kernel with retpolines will protect the kernel but only the kernel. Applications could still read each others memory but not the kernels memory. Recompiling everything will protect everything (except the firmware so you still need the microcode fix).

 *alex-kas wrote:*   

> Also, as tholin wrote in the previous post, devs try or at least think to implement ELF changes which would be used by the kernel in order to speedup things IF the program with such an ELF has a bit indicating the retpoline protection switches were used. Is it a joke? I will compile my binary my way and then put whatever bit you want  And the kernel would blindly think it is a wise and proper app???
> 
> 

 

The new bit would be use to tell the kernel that a program is protected by itself (with retpolines) so that the kernel doesn't have to protect it (using the new microcode functionality). You could compile a program without retpolines and set the bit. Then your program could be attacked by other program but in that case you have yourself to blame. The bit is only used to say a program i immune to attack, it says nothing about how trustworthy a program is.

 *alex-kas wrote:*   

> So, back to the question: what is the background for aiming to the whole box re-compilation? And, if yes, how to do the same with external/binary packages??? And if yes, recompile and yes, no control of binary packages then how to protect if these are malicious intruders???
> 
> 

 

Binary packages without retpolines would have to be protected my the kernel using using the new microcode functionality. This has nothing to do with binary packages being evil.

----------

## mv

There are a lot of different things mixed here:

The point of spectre v2 is that a malevolent program can steal "any" data from every program it can access (e.g. by calling) which is not compiled with retpoline.

Since the kernel can be called by any program and can access any data, this is the most critical part: If this is not protected against stealing data, every other protection makes no sense.

But you will of course want to protect (i.e. recompile with retpoline) as well all other programs which deal with (or can be used to access) sensible data: All login/encryption/mail/... software

 *PrSo wrote:*   

> counter action should be done by authors of VM's, ie. Qemu [...]
> 
> With mitigation applied to kernel host machines should be safe.

 

If VM/Qemu/... itself uses retpolines in a proper way (and has no other security hole) the host machines are "safe" in the sense that one virtual machine cannot steal data from another one. But inside one virtual machine programs can happily steal data from each other unless these programs protect themselves against data theft by using retpoline.

 *Quote:*   

> Same regards to web browsers. Firefox applied own patches, and so Chrome

 

This is again a different story: Browsers attempt to make it harder to steal data by restricting the possibilities of browsers. So with a "protected" browser it is not so simple for a malevolent website (even if you access it with activated javascript) to read all data it wants from all of your programs which still lack repoline support. However, "not so simple" really means what it says; it is not impossible but only some additional obstacles have been built (e.g. by giving the website less accurate timers).

----------

## PrSo

With the assumption that every program should be treated as "untrusted" with a malicious code inside? Fair enough.

But even author of retpoline patches says:

 *Quote:*   

> Binaries with shared linkage
> 
> While our initial focus has been the protection of operating system and hypervisor-type targets, there are classes of user application for which this coverage is valuable.  In these cases, it should be called out that shared linkage and runtimes will lead to frequent additional interactions with indirect branches. Ubiquitous examples include the Program Link Table (PLT) and dynamically loaded standard libraries.  We will be publishing additional optimization notes and techniques for these cases.

 

source:

https://support.google.com/faqs/answer/7625886

As I my understanding is correct Spectre is cpu architectural design flaw, so without "in silicon" change it is impossible to eliminate the threat, and all those mitigations should only minimize the probability of stealing other program memory.

In that case I also wonder if there would be any problems with compile everything with retpoline, similar like with LTO and graphite.

----------

## NeddySeagoon

PrSo,

The software fix reduces or eliminates the threat by reducing or eliminating the use of the flawed silicon.

This comes at a performance cost.

Silicon changes will be required so that the retpoline patches are no longer required.

Once revised silicon is available, the retpoline patches will need to be dropped or the lost performance will not be regained.

----------

## mv

 *NeddySeagoon wrote:*   

> Once revised silicon is available, the retpoline patches will need to be dropped or the lost performance will not be regained.

 

The lost performance can never be regained: The whole prediction technique is vulnerable.

If newer processor will be faster then only because of other innovations, but not because of "regaining" the loss...

If I understand correctly, the current retpoline technique does not add additional overhead but just exactly prevents prediction.

----------

## NeddySeagoon

mv,

When you prevent prediction, you lose the performance that correct prediction would have gained.

That's a net loss to CPU throughput. 

 *mv wrote:*   

> The lost performance can never be regained: The whole prediction technique is vulnerable. 

 

That may be an implementation detail. I don't know enough about the implementation of branch prediction to know if it can be made safe.

There will be a lot of effort going into making it work safely.

----------

## Pearlseattle

 *tholin wrote:*   

>  *alex-kas wrote:*   Can anyone explain me why should someone think about recompiling something more than a kernel??? I mean to defend from Specter. I was thinking that having kernel compiled with the retpoline switches I kinda guarantee this kernel will help me protecting my box. Am I wrong?
> 
>  
> 
> Compiling the kernel with retpolines will protect the kernel but only the kernel. Applications could still read each others memory but not the kernels memory. Recompiling everything will protect everything (except the firmware so you still need the microcode fix).
> ...

 

Well, I'm following this whole story since Jan 3 and everything has been very exciting and dynamic and etc... but to sum it up, especially regarding the fixes, I admit that I did not quite understand anything, hehe... .

Therefore, the questions posted by alex-kas kind of mirror my own ones.

I think that I do understand quite well the part involving the kernel being protected (by using retpolines, Kpti, whatever... AND the firware of case of Intel CPUs) => the kernel is protected no-matter-what, and that's it, right?!

But I still do not understand basically "everything else":

1) The new bit would be use to tell the kernel that a program is protected by itself (with retpolines) so that the kernel doesn't have to protect it (using the new microcode functionality)

The kernel would therefore "speculate" (hehe) that the program hasn't been corrupted? Meaning that if I'm a great cracker and I find out that I can (re/over)write program X on my target's server I'll just flip the bit and I'll have access to everything (not related to the kernel)?

2) Binary packages without retpolines would have to be protected my the kernel using using the new microcode functionality. This has nothing to do with binary packages being evil.

Basically same thing as #1, but let's say that somebody flips the retpoline-bit in a binary package (being nVidia drivers, Teamviewer, Chrome, etc...) => then just because of "THAT ONE PACKAGE" the whole environment would potentially be back to stoneage (if anyone uses that SW to find a flaw in the environment being OS or other apps), or not?

1+2)

Ok, summarized, I'm basically asking the following:

in a best-case-scenario, are we back to stoneage every-single-time that an attacker manages to introduce and execute on a host ANY ((pre)compiled) code that has the retpoline-flag switched on (as fake) which in turn woud exploit the meltdown/spectre analysis to gather critical info about the running kernel/programs (to then of course access through "normal" app and/or kernel bugs to then gain control of the target device)?

Thaaaaaaks a lot!

 :Very Happy: 

Edit: added some details 3 minutes later

----------

## mv

 *Pearlseattle wrote:*   

> I'll just flip the bit and I'll have access to everything (not related to the kernel)?

 

No, the opposite: If you flip the bit, that program (and everything it can access) can potentially be accessed "from the outside". So if it is a program which is run with root permissions, everything can potentially be accessed "from the outside". But if in attacker can manage to flip the bit in a program which is run with root permissions, he can do everything else with this program, anyway, and in particular directly access and send the data where he wants to.

----------

## mv

 *NeddySeagoon wrote:*   

> When you prevent prediction, you lose the performance that correct prediction would have gained.
> 
> [...]
> 
> That may be an implementation detail.

 

It is not: If you don't lose time in one case but lose it in another, this can always be measured and used to understand which branch you have taken.

The only "solution" is that you do not loose time in any case; but this means simply higher internal parallelism and not prediction.

----------

## mv

The released binuitils-2.30 does not seem to know -z,retpolineplt:

```
$ grep -Ri retpo binutils-2.30 || echo :\(

:(
```

Edit: I guess the newest gold linker from llvm does.

----------

## lagalopex

 *mv wrote:*   

> The released binuitils-2.30 does not seem to know -z,retpolineplt

 

Maybe have a look at their ml.

tl;dr:

 *Florian Weimer wrote:*   

> I expect that compiler support for indirect branch rewriting together with -fno-plt is sufficient.  There is simply no need to put any code into binutils at this point.

 

----------

## The Main Man

With gcc-7.3.0 :

```
$ cat /sys/devices/system/cpu/vulnerabilities/*                                                                                                                                                         

Mitigation: PTI

Vulnerable

Mitigation: Full generic retpoline
```

----------

## gengreen

I applied the retpoline patch on a kernel 4.9.74 (minipli) and have rebuild my entire system with gcc 7.3.0 p1.0 on my glibc system.

Unlike the most recent kernel, I do not have 

```
/sys/devices/system/cpu/vulnerabilities/
```

 to give me some information about the effect of retpoline on my system, but the performance did decrease badly, especially with qemu.

I'm currently rebuilding my musl system with gcc 7.3.0 and a retpoline kernel too, I except it will be more or less the same in loss of performance.

----------

## Elleni

 *Elleni wrote:*   

>  *PrSo wrote:*    *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.
> ...

 

Can anyone say something on amd ryzen really not being affected or may it be advisable to enable autodisabled PTI even on amd ryzen?

----------

## mv

The new gcc flags cause some problems on x86 (i.e. 32 bit):

gcc-7.3.0 and rust won't compile with -fno-plt (segfault), and firefox won't compile if any of -mindirect-branch=thunk or -mfunction-return=thunk is used.

There might be more (perhaps also for 64 bit...): This git repository will probably be updated regularly.

Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you...

----------

## kernelOfTruth

 *mv wrote:*   

> The new gcc flags cause some problems on x86 (i.e. 32 bit):
> 
> gcc-7.3.0 and rust won't compile with -fno-plt (segfault), and firefox won't compile if any of -mindirect-branch=thunk or -mfunction-return=thunk is used.
> 
> There might be more (perhaps also for 64 bit...): This git repository will probably be updated regularly.
> ...

 

*Subscribing*

good to know !

Exactly what I was attempting to do: compile firefox   :Confused: 

Thanks for saving me (and probably others) some time with troubleshooting to get firefox to compile, mv

I'll wait and see what will be done to get firefox to work with those retpoline flags ...

4.14.16 with gcc 7.3:

 *Quote:*   

> cat /sys/devices/system/cpu/vulnerabilities/* 
> 
> Mitigation: PTI
> 
> Vulnerable
> ...

 

----------

## Naib

```
uname -a; for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/}:$(cat $f)" ;done

Linux fluidmotion 4.15.0-gentoo #1 SMP PREEMPT Mon Jan 29 23:30:55 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

meltdown:Not affected

spectre_v1:Vulnerable

spectre_v2:Mitigation: Full AMD retpoline

```

just need to sort out v1

----------

## pjp

 *Elleni wrote:*   

> Can anyone say something on amd ryzen really not being affected or may it be advisable to enable autodisabled PTI even on amd ryzen?

  I can only add another reference of someone else also expressing interest. Until I learn otherwise, I'm considering it a desirable security setting.

 *Bug 643228, Comment 11 wrote:*   

> I wish to present something else for consideration. The KAISER patchset was originally intended to harden the implementation of KASLR in the Linux kernel [1] [2]. It was hastily re-purposed to address Meltdown, and re-branded as KPTI in the process. Later, Thomas Lendacky submitted a patch that prevents KPTI from being activated by default for AMD processors - a patch that gentoo-sources is now carrying. AMD's pretext is that their processors are not affected by Meltdown.
> 
> My concern over this situation is that it may put AMD processors at a disadvantage in lieu of the security issue that KAISER was originally intended to protect against. That is, KASLR may be unnecessarily weakened on AMD processors, by default. Indeed, the "Practical Timing Side Channel Attacks Against Kernel Space ASLR" whitepaper [3] specifically tested their attacks on AMD processors, which were found to be affected.
> 
> Assuming that I'm correct, AMD users who enable both CONFIG_RANDOMIZE_BASE and CONFIG_PAGE_TABLE_ISOLATION will need to explicitly pass "pti=on" as a kernel option in order to harden KASLR, whereas Intel users will not. I realise that this is a less pressing concern then attending to Meltdown, but it struck me as being worthy of mention.

 

----------

## Hossie

So what compilation options for userspace is recommended now?

```
-mindirect-branch=thunk -mfunction-return=thunk
```

?

----------

## mv

 *Hossie wrote:*   

> So what compilation options for userspace is recommended now?

 

I would guess

```
-O2 -fno-plt -mindirect-branch=thunk -mfunction-return=thunk
```

for gcc. And with the next clang, I guess either

```
-O2 -fno-plt -mretpoline
```

or (if this should be supported by the llvmgold plugin):

```
-O2 -Wl,-z,repolineplt -mrepoline
```

----------

## transpetaflops

 *mv wrote:*   

> And with the next clang, I guess either
> 
> ```
> -O2 -fno-plt -mretpoline
> ```
> ...

 

Just out of curiosity. Do I define CFLAGS/CXXFLAGS specifically for clang somewhere in make.conf? I don't remember seeing it in the handbook.

----------

## mv

 *transpetaflops wrote:*   

> Do I define CFLAGS/CXXFLAGS specifically for clang somewhere in make.conf?

 

portage does not care which compiler you use, i.e. these variables just refer to your currently configured compiler.

If you want to switch compilers on a per-package bases, you might want to use app-portage/portage-bashrc-mv (from the mv overlay) which a few days ago has been updated to filter by default the correspondingly unknown new flags for gcc/clang.

----------

## lagalopex

 *mv wrote:*   

> I would guess
> 
> ```
> -O2 -fno-plt -mindirect-branch=thunk -mfunction-return=thunk
> ```
> ...

 

That should be described in wiki (Project:Security/Vulnerabilities/Meltdown and Spectre) as well?

Pushing a news item would be nice as well, right?

----------

## transpetaflops

 *mv wrote:*   

> portage does not care which compiler you use, i.e. these variables just refer to your currently configured compiler.

 

If gcc and clang are using different parameters for the mitigations, do we just add them all to CFLAGS and the currently used compiler will just drop the parameters it doesn't understand or how do we handle this?

----------

## mv

 *transpetaflops wrote:*   

> If gcc and clang are using different parameters for the mitigations, do we just add them all to CFLAGS and the currently used compiler will just drop the parameters it doesn't understand or how do we handle this?

 

The compiler might spit errors/warnings on unknown flags. If you use portage-bashrc-mv, it will filter the flags before they reach the compiler.

----------

## mv

world is now rebuilt with the new flags on x86 and am64.

On amd64, some standard programs (zsh, tmux, and xterm) sometimes segfaulted in glibc while compiling, but this might be due to a mixture of already loaded and freshly compiled libs in different formats.

After a reboot on amd64, X did not start: It seems that xorg-server and x11-drivers/* (at least xf86-input-libinput) do not like -fno-plt.

After recompiling these programs with -fno-plt filtered, X starts.

So far, everything appears to be stable on amd64.

x86 successfully recompiled, but it is not tested yet.

----------

## ChrisJumper

 *mv wrote:*   

> world is now rebuilt with the new flags on x86 and am64.
> 
> 

 

Which Flags did you use?

```
-O2 -fno-plt -mretpoline
```

```
O2 -fno-plt -mindirect-branch=thunk -mfunction-return=thunk
```

And why no-plt in the first place? Did it affect the speculative execution/branch prediction in a Way that make an attack more difficult?

Gloss about plt:

Position independent Code (PIC)

plt (process linkage table)

Some Code seems to need the plt, especially if you have position dependent code (non-PIC), in combination with dynamically linked/use shared libraries. Because on position dependent code the compiler have no chance to forecast actual used address for functions, later at runtime. That depend on the used shared libraries, so the compiler just use an ordinary call instruction.

Now its the Linkers job when it recognize a relocation of a not locally used symbol to generate a plt entry that load the Address from the Global Offset Table and create a jump to it.

So with the plt you got a function call working on dynamically linked libraries, without a need to modify the position dependent Code (non-PIC).

I suppose those packages who dislike no-plt needs to be static linked? Did not try it by myself just a suggestion.

----------

## mv

 *ChrisJumper wrote:*   

> Which Flags did you use?

 

A lot of flags, but new were only

```
-fno-plt -mindirect-branch=thunk -mfunction-return=thunk
```

For the records: My other “standard” flags are:

```
CPPFLAGS='-DNDEBUG -DNO_DEBUG'

CXXFLAGS='-march=native -O2 -fno-ident -pipe -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-O9 -Wl,--enable-new-dtags -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,--relax -Wl,--as-needed -Wl,--build-id=none -fstack-protector-strong -fstack-check=specific -fomit-frame-pointer -fno-common -g0 -ffast-math -fmerge-all-constants -ftree-partial-pre -fno-unwind-tables -fno-asynchronous-unwind-tables -fvect-cost-model -fgcse-sm -fgcse-las -fweb -finline-functions -fgcse-after-reload -fpredictive-commoning -fdirectives-only -ftree-switch-conversion -fira-loop-pressure -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -fivopts -fdiagnostics-color=always -freorder-functions -fdevirtualize-speculatively -fno-semantic-interposition -frename-registers -flto -fuse-linker-plugin -flto-partition=none -flto-odr-type-merging -fvisibility-inlines-hidden -fno-enforce-eh-specs -fnothrow-opt -D_GLIBCXX_ASSERTIONS'
```

(and CFLAGS, LDFLAGS, FFLAGS, FCFLAGS, F77FLAGS a certain subset of these), and I omitted some processor-specific flags in this list (which are contained in -march=native if the latter is not filtered).

However, do not consider this full list as a general recommendation: Some are quite risky, and I filter a lot of them for specific packages (see here for the exceptions)

 *Quote:*   

> And why no-plt in the first place? Did it affect the speculative execution/branch prediction in a Way that make an attack more difficult?

 

That's what I suppose. Of course, this cannot be really checked except by attempting to write an exploit...

 *Quote:*   

> if you have position dependent code (non-PIC), in combination with dynamically linked/use shared libraries

 

Nowadays, libraries with non-PIC practically don't exist. (Moreover, I use -pie -fPIE -Wl,-z,now -Wl,-z,relro since years, so even position-dependent non-libraries are rare on my systems.)

 *Quote:*   

> I suppose those packages who dislike no-plt needs to be static linked?

 

Essentially, this is xorg-server (and the X drivers), and these cannot be statically linked: The reason why they do not like this flag is that (according to my understanding) they do not use ld.so directly as other packages but instead some hand-crafted X-only runtime linker wrapper which has less/different features. To my knowledge this is one of the reasons why wayland was born: to get rid of such ancient bloat which really blocks progress.

My “solution” is to avoid -fno-plt for these few packages (I had done this earlier with -Wl,-z,now, of course).

Edit: Add other flags, refer to exceptions, fix typos.

----------

## mv

 *mv wrote:*   

> x86 successfully recompiled, but it is not tested yet.

 

A quick test (booting, running X, testing a few programs) showed so far no problems, either.

For neither system I could observe an obvious slowdown for my usual tasks. Of course, I expect that this might be different for certain long-running calculations, but for standard development (compiling etc, including the emerge -e world itself), I did not recognize an observable slowdown.

----------

## eccerr0r

Is the only way to get x86 KPTI from a git repo or is there a released version now?

Have anyone seen of a live exploit now?  I'd love to be wrong but still think a general purpose exploit is hard to write especially with KASLR.

 *mv wrote:*   

> On amd64, some standard programs (zsh, tmux, and xterm) sometimes segfaulted in glibc while compiling, but this might be due to a mixture of already loaded and freshly compiled libs in different formats.

 

Crap, more non-deterministic behavior due to ASLR? :-( One would hope things are deterministic.

----------

## mv

 *eccerr0r wrote:*   

> Crap, more non-deterministic behavior due to ASLR? :-( One would hope things are deterministic.

 

The crashes occurred only while working on the system during the world rebuild: After the reboot, I had no such crashes anymore (so far). So it seems that my conjecture is true that these crashes were caused by using libraries in mixed versions (partially through programs loaded before the rebuild and partially after the rebuild with the new flags -fno-plt ...). I do not think that ASLR has anything to do with this.

----------

## eccerr0r

Did you have to do anything to get beyond the crash or simply restarting will succeed (regardless if incorrect versions are in play)?  The latter would imply non-determinism.  If you mean adding -f no-pit will workaround the crash, then that's okay...

----------

## transpetaflops

 *eccerr0r wrote:*   

> Have anyone seen of a live exploit now?  I'd love to be wrong but still think a general purpose exploit is hard to write especially with KASLR.
> 
> 

 

Symantec has a Trojan listed referencing CVE-2017-5754 at least or it may just be a general info. I'm not certain.

https://www.symantec.com/security_response/writeup.jsp?docid=2018-011115-0609-99

----------

## eccerr0r

 *transpetaflops wrote:*   

> Symantec has a Trojan listed referencing CVE-2017-5754 at least or it may just be a general info. I'm not certain.
> 
> https://www.symantec.com/security_response/writeup.jsp?docid=2018-011115-0609-99

 

From the wording it seems like it's just a heuristic added to antivirus, but no actual code in the wild.  Theoretically it should trigger off of the PoC code.

Also note "Risk Level 1: Very Low" which somewhat fits with my guess that it is hard to exploit but easy to demonstrate...

----------

## mv

 *eccerr0r wrote:*   

> simply restarting will succeed

 

Rebooting succeeded.

----------

## eccerr0r

 *mv wrote:*   

>  *eccerr0r wrote:*   simply restarting will succeed 
> 
> Rebooting succeeded.

 

Err. No, I meant when emerge/gcc fails, you had to do something to retry it, whether you did nothing and rerun emerge, or added an option to a config file and emerge.  If you did nothing and restarted the emerge and it succeeded the second time around - this would be a determinism problem that would be alarming.

----------

## mv

 *eccerr0r wrote:*   

> Err. No, I meant when emerge/gcc fails

 

It was not emerge/gcc that segfaulted, but other programs I was using during the emerge (not related to the emerge): xterm, tmux, zsh, once also firefox crashed; usually when they should display something. The corresponding X session (and some or even all of these programs) had been open during the whole emerge world process.

----------

## eccerr0r

Ah, thanks for clearing that up.  Something like that is quite expected indeed.

----------

## mike155

Intel just released a microcode revision guide, which contains detailed list  of currently planned microcode updates (MCUs). 

The list contains version numbers of

- pre-mitigation MCUs

- stopped MCUs

- new (planned) productions MCUs

I found the link in this message.

----------

## Luke-Jr

 *mv wrote:*   

> Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you...

 Why not? What part of -O2 is important? (-O2 contains optimizations that make debugging annoying...)

----------

## mv

 *Luke-Jr wrote:*   

>  *mv wrote:*   Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you... Why not? What part of -O2 is important?

 

I did not try the switches implied by -O2 individually, but -O1 alone was not enough.

My test is very trivial: I have just compiled the spectre test with -mindirect-branch=thunk and with/without -O2 ...

 *Quote:*   

> O2 contains optimizations that make debugging annoying.

 

Why would somebody want to enable spectre mitigation patches in program which is just compiled for being debugged?

(Also, in my experience, debugging is not really harder with -O2. But then again I usually find the bugs by reading the code carefully instead of running a debugger, unless it is a code generation or compiler optimization bug in which case I would have to use -O2 or better anyway...)

----------

## Luke-Jr

 *mv wrote:*   

>  *Luke-Jr wrote:*    *mv wrote:*   Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you... Why not? What part of -O2 is important? 
> 
> I did not try the switches implied by -O2 individually, but -O1 alone was not enough.
> 
> My test is very trivial: I have just compiled the spectre test with -mindirect-branch=thunk and with/without -O2 ...

 

AFAICT, that test is just for Spectre variant "1a" aka variant 4, which is NOT a CPU bug, but merely a bug in sandboxing frameworks.

Anyhow, strangely enough... turning on every -O2 option by hand does not cause that test to fail (although I confirmed -O2 does)!

So -O2 is doing something undocumented and that doesn't affect the output from -Q --help=optimizers,warnings,params,common,undocumented :/

The minimal I could get the test to fail with was: -O1 -fgcse -finline-small-functions

 *mv wrote:*   

> 
> 
>  *Quote:*   O2 contains optimizations that make debugging annoying. 
> 
> Why would somebody want to enable spectre mitigation patches in program which is just compiled for being debugged?

 I prefer that if a program crashes, I can immediately debug what happened, so I try to build everything debuggable.

BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead.

Is -mindirect-branch-register completely unnecessary? (Why was it backported?)

----------

## mv

 *Luke-Jr wrote:*   

> So -O2 is doing something undocumented

 

Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches. I suppose that a whole optimization phase (or at least a considerable part of it) is missing without -O2.

 *Quote:*   

> I prefer that if a program crashes, I can immediately debug what happened, so I try to build everything debuggable.

 

For backtraces and such things, optimizations practically do not hurt: If one roughly knows where it crashed, one can guess whether it is a buffer overflow or a null pointer assignment or something else. There is no need to follow every single instruction step by step in such a case, in particular since a bug causing a crash usually happened somewhere else, anyway (wrong arguments to the crashing function or of other data, perhaps caused by a buffer overflow in a completely different place).

 *Quote:*   

> BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead.

 

How do you do this? I never found a convenient way for it: AFAIK, there is not a file which is read on startup, but it seems to be compiled in hard, i.e. you really have to switch binaries?

 *Quote:*   

> Is -mindirect-branch-register completely unnecessary? (Why was it backported?)

 

I do not really understand the purpose of this switch. My guess is that it just modifies a detail in the implementation of -mindirect-branch (and of -mfunction-return?) which is only important in connection with =extern. In particular, my guess is that the "extern" part provided by the kernel will not work without this switch and that with =thunk it only influences the retpoline runtime (if at all). But this is only a guess, after I received no reply on my corresponding question. If somebody knows more, please tell...

----------

## Luke-Jr

 *mv wrote:*   

>  *Luke-Jr wrote:*   So -O2 is doing something undocumented 
> 
> Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches.

 Not documented is the same as undocumented.  :Smile: 

 *mv wrote:*   

>  *Quote:*   BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead. 
> 
> How do you do this? I never found a convenient way for it: AFAIK, there is not a file which is read on startup, but it seems to be compiled in hard, i.e. you really have to switch binaries?

 

I throw a patch file in /etc/portage/patches/sys-devel/gcc/

Still working on my revised one, however - it seems parts of libgcc (crtbegin/end?) are built with -fno-inline, which breaks the retpoline (and in my patch, throws an error at compile-time).

Fetching the GCC git overnight to see if I can identify the reason it's build with -fno-inline and whether it's safe to remove that...

 *mv wrote:*   

>  *Quote:*   Is -mindirect-branch-register completely unnecessary? (Why was it backported?) 
> 
> I do not really understand the purpose of this switch. My guess is that it just modifies a detail in the implementation of -mindirect-branch (and of -mfunction-return?) which is only important in connection with =extern. In particular, my guess is that the "extern" part provided by the kernel will not work without this switch and that with =thunk it only influences the retpoline runtime (if at all). But this is only a guess, after I received no reply on my corresponding question. If somebody knows more, please tell...

 IIRC the kernel doesn't use the switch either.

----------

## mv

 *Luke-Jr wrote:*   

>  *mv wrote:*    *Luke-Jr wrote:*   So -O2 is doing something undocumented 
> 
> Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches. Not documented is the same as undocumented. 

 

I think there is a misunderstanding of the double negation I used.

 *Quote:*   

> I throw a patch file in /etc/portage/patches/sys-devel/gcc/

 

That's the inconvenient way I meant. So it is not possible to switch back easily (without implementing anti-options as well). For instance, while this might be the right approach for spectre in user space it calls for trouble for e.g. kernel compilation or kernel modules.

 *Quote:*   

> IIRC the kernel doesn't use the switch either.

 

```
$ grep -R indirect-branch-register .

./arch/x86/Makefile:    RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern -mindirect-branch-register)
```

----------

## mv

The segfaults have occurred again.

They occurred while (and probably only while) I was re-compiling chromium. I had used jumbo-build because there was a speedup (I had 8GB RAM and 20 GB Swap); when disabling jumbo-build there was still a crash, but only one.

So it seems that the crashes are perhaps related with the kernel OOM-killer. Can it be that the OOM-killer does not log but only causes segfaults? Somehow I have doubts that this is related to retpoline. Here are 2 typical messages:  */var/log/syslog/current wrote:*   

> 13:56:35 03.02.18 [kernel] zsh[8462]: segfault at 0 ip ... sp ... error 4 in libc-2.25.so[...]
> 
> 13:58:48 03.02.18 [kernel] xterm[25816]: segfault at 18 ip ... sp ... error 4 in libc-2.25.so[...]

  Also a daemon written in perl segfaulted during chrome compilation while it did nothing else than listening to a socket...

----------

## Spargeltarzan

Hi,

I am not seeing the forest with all the trees any more. With kernel 4.14.18, microcode-update, gcc7.3 and binutils-2.30 the speed47 spectre-meltdown-checker reports "not vulnerable" for all three variants. 

The output of /sys/devices/system/cpu/vulnerabilities/* is:

```

cat /sys/devices/system/cpu/vulnerabilities/*  

Mitigation: PTI

Mitigation: __user pointer sanitization

Mitigation: Full generic retpoline

```

What do we win when modifying the CFLAGS? And what should we add, only "-mindirect-branch=thunk"? some posts before there was a discussion about it only when no microcode update is used, maybe someone can summarize us what we should or could do here...

Thank you!

----------

## Luke-Jr

 *mv wrote:*   

> So it is not possible to switch back easily (without implementing anti-options as well).

 There are already anti-options. It's just a matter of defaults and errors to prevent accidentally breaking the retpoline.

----------

## watersb

I found a fork of the Spectre demo that was tweaked for Mac PowerPC, and warped it very slightly to compile on Linux with GCC 7.3.0 -- mostly a matter of replacing calls to ppc_intrinsics with their GCC_builtin equivalents.

Spectre Demo Source.c via Github Gist

The minimal set of CFLAGS that would toggle the success of the Spectre demo were 

```
-O2 -fno-plt -fno-common
```

. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og. 

Note that this attack relies upon cached data; it is interesting (for some value of...) to run the demo binary repeatedly, and see how the snooped data comes and goes. Optimization levels below -O2 or -Og and the secret string shows up almost immediately, if not then it converges on the secret string. With -O2, any portions of the secret string seem to quickly get flushed out: the hack can't get to the secret, and repeated attempts seem to make it less successful rather than more so.

```
CFLAGS = -std=c99 -D__POWERPC__

MITIGATE = -O2 -pipe -fno-plt -fno-common

PROGRAM = spectre.out

SOURCE  = Source.c

all: $(PROGRAM)

$(PROGRAM): $(SOURCE) ; $(CC) $(CFLAGS) -o $(PROGRAM) $(SOURCE)

clean: ; rm -f $(PROGRAM)

safe: $(SOURCE)

   $(CC) $(CFLAGS) $(MITIGATE) -o $(PROGRAM) $(SOURCE)

```

"make safe" to compile with those additional flags, or just "make" to build the demo without them.

----

Linux g2ppc-mini 4.15.3-gentoo #1 Tue Feb 13 20:18:30 MST 2018 ppc 7447A, altivec supported PowerMac10,1 GNU/Linux

----------

## mv

 *watersb wrote:*   

> The minimal set of CFLAGS that would toggle the success of the Spectre demo were 
> 
> ```
> -O2 -fno-plt -fno-common
> ```
> ...

 

I can confirm that this also suffices on x86_64 (for the unforked code).

----------

## watersb

Thanks mv for your per-package CFLAGS system.

I am able to set a global CFLAGS for Spectre Mitigation, but I have already run into some packages that run afoul of multiple symbol definitions with -fno-common.

/etc/portage/package.cflags makes it easy to filter CFLAGS.

```
net-misc/openntpd        +fno-common
```

----------

## mv

 *watersb wrote:*   

> some packages that run afoul of multiple symbol definitions with -fno-common.

 

The file portage-env-mv/package.cflags/all-systems contains filtering rules for this (and several other flags); flags with more exceptions (pie, flto, ...) are covered in separate flies in portage-env-mv.

----------

## tholin

 *watersb wrote:*   

> Spectre Demo Source.c via Github Gist
> 
> The minimal set of CFLAGS that would toggle the success of the Spectre demo were 
> 
> ```
> ...

 

The vulnerable code (victim_function) and the attacking code (readMemoryByte) are in the same program and are compiled with the same flags. You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous.

----------

## mv

 *tholin wrote:*   

> Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance.

 

True: there is no guarantee that the code is non-vulnerable, only because certain CFLAGS are used.

But if these CFLAGS make the compiler produce less vulnerable code in at least some typical exploit scenarios, one should better use these.

----------

## watersb

 *tholin wrote:*   

> You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent.  Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous.

 

(emphasis mine)

Yes. Crucial to understand these flags are not everything needed, and that we cannot defend against all such attacks with compile-time settings.

I do like to explore the compiler results, and simple Proof-of-Concept toys are fun for me; I lack the experience which might lead me to spot vulnerabilities myself.  As the toolchain gets better at explaining potential errors, I try to learn from the warnings and look at source code.

If the mitigations lead to better-behaved code, then that's a win. I hope. Alas, "better-behaved" is of course not the same for all of this code: adheres to formal spec? doesn't crash? rejects insane input?

Thanks, tholin, for the does of reality.  :Smile: 

----------

## blopsalot

here's my little update. i have added '-mindirect-branch*' to ALLOWED_FLAGS and have been testing using -mindirect-branch=thunk-inline universally. i am stabilizing gold and lto as well, so i cannot say safe for production yet, but I have experienced ZERO build failures as a result of using thunk-inline with otherwise safe flags.

ps: here's everything u need to know about setting per package compiler options:

https://wiki.gentoo.org/wiki//etc/portage/package.env

https://wiki.gentoo.org/wiki/Clang

----------

## mv

 *blopsalot wrote:*   

> added '-mindirect-branch*' to ALLOWED_FLAGS

 

How did you do that? Did you patch the gentoo repository locally?

----------

## blopsalot

yes, it's in flag-o-matic.

----------

## mv

 *blopsalot wrote:*   

> yes

 

I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch?

----------

## P.Kosunen

https://newsroom.intel.com/news/latest-intel-security-news-updated-firmware-available/

----------

## Tony0945

 *mv wrote:*   

>  *blopsalot wrote:*   yes 
> 
> I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch?

 

IIRC, an eclass in /usr/local/portage will override one in /usr/portage. I have some old ebuilds with eclasses that have been removed from the tree in my /usr/local/portage.  Also, you could add a script to postsync_hooks (sic?) that copies the altered eclass over after every sync.

----------

## pickd.mask

Hello.

When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:

 *Quote:*   

> CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> 
> * Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> 
> * Kernel has array_index_mask_nospec:  YES  (1 occurence(s) found of 64 bits array_index_mask_nospec())
> ...

 

I've tried to find info about this patch myself, but it seems like it's either hard to find or my english makes it hard.

So i'm curious if anybody knows what this patch is and if we, Gentoo users, actually need it or not. 

Any advice would be appreciated.

----------

## mv

 *Tony0945 wrote:*   

> IIRC, an eclass in /usr/local/portage will override one in /usr/portage.

 

I haven't checked, but I doubt it. For instance, one can configure portage to store the repository in /srv/... or /var/...; from where should the overrides come? Still some hard-coded /usr/local/portage?

It is possible to specify the repository's masters, but unfortunately, this information is stored in the repository itself: This can be overridden, but then you also have to override e.g. every layman repository you use. (Moreover, I think the repository itself is checked for the eclasses before checking the masters, so perhaps it won't even work to override eclasses but just to provide removed eclasses. With this restriction it also makes sense why that information is stored in the repository itself.)

 *Quote:*   

> Also, you could add a script to postsync_hooks

 

Yes, this is one of the ideas I mentioned in my post, but it is a horrible hack which one day will fall back on you. (It might also conflict with git syncing...) Also, it breaks the md5 cache, so the metadata information of the ebuilds becomes worthless and has to be regenerated.

----------

## Hossie

 *pickd.mask wrote:*   

> Hello.
> 
> When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:
> 
>  *Quote:*   CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
> ...

 

As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.

The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.

Dont take this all as facts, just my state of knowledge.

----------

## pickd.mask

 *Hossie wrote:*   

> 
> 
> As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.
> 
> The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.
> ...

 

Thanks, that's valuable info   :Smile: 

----------

## MaDDeePee

Sry if this is a stupid question....but may i ask:

Is this current problem the reason why all kernels since 4.9.76 are still marked "testing"?

We're at 4.15.4 right now...

https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

Thanks  :Smile: 

----------

## benchaney

Sort of. There was an unrelated issue that cause all 4.14 kernels to be marked as unstable. But I do think that this issue is related to why we some other versions are slow to make it in to stable.

----------

## Luke-Jr

 *tholin wrote:*   

>  *watersb wrote:*   Spectre Demo Source.c via Github Gist
> 
> The minimal set of CFLAGS that would toggle the success of the Spectre demo were 
> 
> ```
> ...

 This doesn't make sense to me. The victim is the "secret" variable, not code. If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? Am I missing something?

I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd). Assuming the attacker can use assembly, I don't see any way to get effective protection against this attack... :/

----------

## mv

 *Luke-Jr wrote:*   

> If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

 

If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser).

----------

## Luke-Jr

 *mv wrote:*   

>  *Luke-Jr wrote:*   If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? 
> 
> If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser).

 Does that mean my mmap example is actually new Spectre variant?

----------

## mv

 *Luke-Jr wrote:*   

>  *mv wrote:*    *Luke-Jr wrote:*   If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? 
> 
> If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser). Does that mean my mmap example is actually new Spectre variant?

 

??? Your question has not the slightest relation with my answer. Your "victiim" simply runs in a context which can read the mmap anyway.

----------

## tholin

 *Luke-Jr wrote:*   

> If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no?

 

That assumes the attacker can put arbitrary code in a process, but if that is possible the attacker can read the process memory even without specter vulnerabilities. That PoC only demonstrates that the cpu got the spectre v1 vulnerably. C code is used and the vulnerable code and attacking code is put in the same program because it's easier to demonstrate the vulnerability that way. Assuming that an attacker can't put arbitrary machine code in a process the attacker has to get the vulnerable code snippet into the victim some other way. Perhaps it was there all along because the programmer put it there without realizing it's dangerous or perhaps the attacker can inject it using the victims own JIT compiler. That's how google's PoC worked.

To fix the vulnerability you have to do something like this to all vulnerable code patterns.

```
 void NOINLINE victim_function(size_t x) {

   if (x < array1_size) {

+    _mm_lfence();

     temp &= array2[array1[x] * 512];

   }

 }
```

Assuming the lfence instruction is serializing this will prevent the vulnerable code pattern from being speculatively executed before the boundcheck completes. 

 *Luke-Jr wrote:*   

> I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd)

 

X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ.

----------

## Luke-Jr

 *tholin wrote:*   

>  *Luke-Jr wrote:*   I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd) 
> 
> X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ.

 But the program segfaults if I try to read directly from it...?

----------

## Hossie

Does anybody know of new microcode releases (that "linux package")? Do distributors have special access / communction channels to intel or do they also just download from that downloadcenter page...

Maybe we should be thinking about collecting bios updates and extracting microcode from there?

I still need it to secure my CentOS KVM VMs :/

----------

## mv

 *tholin wrote:*   

> To fix the vulnerability you have to do something like this to all vulnerable code patterns.

 

Wouldn't it be the task of the compiler to do that? Only the compiler knows when his assembler code actually produces a conditional; and at every conditional the corresponding instruction would have to be put.

Actually, I had assumed that -mindirect-branch=thunk would exactly fix such conditional branches.

----------

## tholin

 *Luke-Jr wrote:*   

> But the program segfaults if I try to read directly from it...?

 

How are you reading the memory?

Perhaps I'm wrong and the kernel got some way to emulate the behavior despite the lack of hardware support on x86.

 *mv wrote:*   

> Wouldn't it be the task of the compiler to do that?

 

Ideally, yes but it won't be easy. You can't put a serializing instruction after every conditional branch because the performance hit is too high. That PoC takes a 98.7% performance drop on my computer after inserting that single lfence instruction. The compiler needs to figure out which branches are vulnerable and only protect them but the compiler doesn't even know which inputs are trusted and untrusted. 

Microsoft has implemented spectre v1 protection in their compiler but as expected it didn't work so well.

https://www.paulkocher.com/doc/MicrosoftCompilerSpectreMitigation.html

"A compiler cannot reliably determine whether arbitrary sequences of instructions will be exploitable. For example, when compiling a function, the compiler often has no way to infer the properties of the parameters that will be passed when the function is called. A post-compilation analysis tool (e.g. using symbolic execution) could do somewhat a better job, but will still be imperfect since code analysis is an inherently undecidable problem."

 *mv wrote:*   

> Actually, I had assumed that -mindirect-branch=thunk would exactly fix such conditional branches.

 

-mindirect-branch=thunk is only for spectre v2 (replacing indirect branches with retpolines) and that's unrelated to spectre v1 (problematic speculation beyond conditional branches).

----------

## Luke-Jr

 *tholin wrote:*   

>  *Luke-Jr wrote:*   But the program segfaults if I try to read directly from it...? 
> 
> How are you reading the memory?

 

```
value[0] = *(uint8_t *)malicious_x;
```

----------

## Hu

Why are you casting a size to a pointer?  That is unlikely to work, especially since it looks like the size isn't even sane in the first place.  victim is a pointer to the mapping.  array1 is unspecified in the linked diff, but based on other context is probably a global array.  So the displacement between them is (1) variable based on the mapping location and (2) meaningless as a pointer.  Accessing it at all is a bug.  Remember the basic rule of C casts: if you cannot explain exactly why you need it, you probably don't need it and should not use it.  If not using it breaks your build, that's probably because your code is wrong.  I suggest removing all non-justifiable casts in your code and rebuilding with -Wall -Wextra.

----------

## tholin

As Hu pointed out malicious_x is a vector no a pointer. It should be the offset between the start of array1 to secret. The original code calls victim_function with malicious_x which will speculatively read from array1[malicious_x]. Since malicious_x is the distance between array1 and secret that read will be out of bounds and end up in secret instead. Even if you change your mmap permission to (PROT_READ | PROT_WRITE) dereferencing malicious_x directly will still segfault. 

The original code is also a bit confused. In main() it tries to print malicious_x like a pointer.

```
printf("Reading at malicious_x = %p... ", (void *)malicious_x);
```

But it's not a pointer and the value printed is gibberish.

If you try to make a write only mapping it will show up in /proc/<pid>/smaps as

```
7f858927c000-7f858927d000 -w-p 00000000 00:00 0
```

So it looks like the mapping is writable and private but not readable. But if you check the actual pagetables from /sys/kernel/debug/page_tables/current_user the same mapping looks like

```
0x00007f858927c000-0x00007f858927e000           8K USR RW                     NX pte
```

So the mapping is really RW. X86 doesn't have write only pagetables.

/sys/kernel/debug/page_tables/current_user shows the pagetables of the process that reads it so you have to read it from the C program.

----------

## blopsalot

 *Hossie wrote:*   

> Does anybody know of new microcode releases (that "linux package")? Do distributors have special access / communction channels to intel or do they also just download from that downloadcenter page...
> 
> Maybe we should be thinking about collecting bios updates and extracting microcode from there?
> 
> I still need it to secure my CentOS KVM VMs :/

 

i am watching supermicro website for westmere. it looks like they going back to yorkfields.

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf

https://www.supermicro.com/support/security_Intel-SA-00088.cfm

----------

## dasPaul

Hi

The "spectre-meltdown-checker" says on my system:

CVE-2017-5753

STATUS:  NOT VULNERABLE

CVE-2017-5754

STATUS:  NOT VULNERABLE

but for 

CVE-2017-5715

STATUS:  VULNERABLE

Is this because I do not yet have compiled with the patched gcc? I currently have gcc-6.4.0-r1.

Should/Can I upgrade to ~7.3.0 and recompile world/kernel? Does 7.3.0 contain the patches?

----------

## blopsalot

 *dasPaul wrote:*   

> Hi
> 
> The "spectre-meltdown-checker" says on my system:
> 
> CVE-2017-5753
> ...

 

they just merged the s390 mitigations a few days ago to the 6-branch. 7.3.0 was kind of rushed, I'm guess i386 will be backported soon though..

----------

## Ska`

Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt

Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now.

----------

## Tony0945

 *Ska` wrote:*   

> Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt
> 
> Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now.

 

I had a few that just needed a package.env setting to specify an older default standard or a changed flag (couldn't tolerate pie, I switched profile at the same time).

----------

## Luke-Jr

 *Ska` wrote:*   

> Since ~7.3.0 had no ~ deps, I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt
> 
> Everything went fine except one package: oath-toolkit. I don't know if the fault is due to the new GCC or what, I already unmerged 6.4.0 so I can't try right now.

 Note that some packages ignore CFLAGS still. :/

I'm playing with this patch to [almost] force it on: https://luke.dashjr.org/tmp/code/gcc-retpoline-default.patch

Problem now is libgcrypt's ebuild doesn't let you configure its optional feature, and one of those (jitter RNG) requires -O0...

Annoyingly, the package maintainer doesn't care about providing the choice Gentoo was once known for: https://bugs.gentoo.org/show_bug.cgi?id=649660

----------

## Tony0945

 *Luke-Jr wrote:*   

> Annoyingly, the package maintainer doesn't care about providing the choice Gentoo was once known for: https://bugs.gentoo.org/show_bug.cgi?id=649660

 

How true!  In your case, it looks like you could make a simple user patch to engage that configuration option.

----------

## Luke-Jr

 *Tony0945 wrote:*   

>  *Luke-Jr wrote:*   Annoyingly, the package maintainer doesn't care about providing the choice Gentoo was once known for: https://bugs.gentoo.org/show_bug.cgi?id=649660 
> 
> How true!  In your case, it looks like you could make a simple user patch to engage that configuration option.

 Yes, it will just be annoying to need to bump it for every new version.

----------

## mike155

 *Quote:*   

> I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt 

 

Why do you do this? Do you really think that your systems will be more secure or more reliable?

Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.

That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.

So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it.

----------

## Tony0945

 *Luke-Jr wrote:*   

> Yes, it will just be annoying to need to bump it for every new version.

 

If it's changing rapidly, it might be easier to maintain the ebuild in local overlay and just put the config line in the ebuild. Most of the time you only have to update the ebuild name, and run "repoman manifest" to keep it in sync. Annoying, but minor. Much less annoying than having your system barf from a surprise change or having useless systemd unit files polluting your system.

EDIT: Just look what happened to xorg-server!  I have more and more system packages in package.mask with <name>::gentoo to just block all the official ebuilds.

----------

## Elleni

 *mike155 wrote:*   

>  *Quote:*   I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt  
> 
> Why do you do this? Do you really think that your systems will be more secure or more reliable?
> 
> Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.
> ...

 

Thanks for clarification, so for the average user, is it sufficient to just update to gcc-7.3 and emerge kernel and perhaps even -e world with this compiler? I have no special cflags in make.conf, just CFLAGS="-O2 -march=znver1" for my ryzen cpu. 

At least grep . /sys/devices/system/cpu/vulnerabilities/* then shows: 

```
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline
```

----------

## mike155

 *Quote:*   

> Thanks for clarification, so for the average user, is it sufficient to just update to gcc-7.3 and emerge kernel and perhaps even -e world with this compiler? I have no special cflags in make.conf, just CFLAGS="-O2 -march=znver1" for my ryzen cpu. 
> 
> 

 

Exactly. That's what I did on my computers and that's what I recommend at the moment.

You could add '-pipe' to your CFLAGS, if you want.

----------

## Luke-Jr

 *mike155 wrote:*   

>  *Quote:*   I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt  
> 
> Why do you do this? Do you really think that your systems will be more secure or more reliable?

 Certainly won't make them less secure or reliable...

 *mike155 wrote:*   

> That's not true for the other 1.000 packages on our computers. As far as I know, none of the developers of those 1000 packages has said: we tested '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt', it's safe, it works, please use it.
> 
> So you compile packages with compiler flags that were not tested for those packages. What you get are binaries which may have errors due to untested compiler flags and which are probably less secure. That's especially true for cryptography software, which is highly optimized and tested with compilers which were available at the time the software was released. Do you really understand what happens if you compile openssl & friends with '-mindirect-branch=thunk -mfunction-return=thunk -fno-plt'? I wouldn't do that if I my objective was to get a secure system. At least not before developers of the software recommend it.

 All it does is emit a slightly different set of instructions that do the same thing, but without triggering speculation.

If this is a problem, it would indicate yet another CPU bug.

----------

## Hu

 *Luke-Jr wrote:*   

> Problem now is libgcrypt's ebuild doesn't let you configure its optional feature, and one of those (jitter RNG) requires -O0...

 That sounds like a bug in the jitter RNG code.  In my opinion, if changing the optimization level affects observed program correctness, then either:The program relies on undefined behavior.The compiler implements the standard incorrectly.Since you mention jitter, I suspect the code is written to rely on failure to optimize.  This is broken.  The code should instead use appropriate directives to explicitly inhibit any optimizations that impact its correctness.

Separately, looking at the libgcrypt code for tiger.c (which uses the mangled optimization flags), I see several opportunities for improvement.  The implementation of the munging is just wrong.  The Makefile:

```
   118   if ENABLE_O_FLAG_MUNGING

   119   o_flag_munging = sed -e 's/-O\([2-9s][2-9s]*\)/-O1/' -e 's/-Ofast/-O1/g'

   120   else

   121   o_flag_munging = cat

   122   endif

   123   

   124   

   125   # We need to lower the optimization for this module.

   126   tiger.o: $(srcdir)/tiger.c

   127      `echo $(COMPILE) -c $(srcdir)/tiger.c | $(o_flag_munging) `
```

The consequences:

```
$ echo '-O2 -O3 -O2' |sed -e 's/-O\([2-9s][2-9s]*\)/-O1/'

-O1 -O3 -O2
```

Last match wins, so by failing to specify a global replace on the sed, the rule doesn't actually work if the user passes more than one -O option.  More generally, the use of `echo ...` works, but feels very fragile.  If upstream insists on munging the flag instead of fixing the code, then the right implementation would be:

```
if ENABLE_O_FLAG_MUNGING

o_flag_munging=-O1

else

o_flag_munging=

endif

tiger.o: $(srcdir)/tiger.c

   $(COMPILE) $(o_flag_munging) -c "$(srcdir)/tiger.c"
```

When munging is enabled, an extra -O1 would be added after all user flags.  When munging is not enabled, the token would be empty and user flags would be fully respected.  However, as said above, I think the code is wrong if it requires a particular optimization level.

Amusingly, tiger.c contains this comment:

```
 * Okay, okay, this is not the fastest code - improvements are welcome.
```

The code might go faster if it was compiled with all standard optimizations.  :Smile: 

I also note that many global constant variables are not actually marked as const, so the compiler might needlessly place them in .data instead of .rdata. *Luke-Jr wrote:*   

> Yes, it will just be annoying to need to bump it for every new version.

 You probably would not need to bump for every version.  Write the patch to modify the upstream build files, put it in /etc/portage/patches under a non-version-qualified path, and it should work unchanged until upstream modifies the patched file in a way that causes a conflict.

As an alternative, get upstream to fix their code so you don't need to patch it, then you will not need to maintain anything locally or convince a Gentoo maintainer to modify the ebuild.

----------

## Hossie

Omg there is a new microcode.

I opened 650428 for some quick bumping.  :Very Happy: 

----------

## mike155

 *Hossie wrote:*   

> Omg there is a new microcode. 

 

Even better, it seems that Intel got it right this time.

I just installed sys-firmware/intel-microcode-20180312 on my Ivy Bridge system, and rebooted:

```
> dmesg -t | head -n 1

microcode: microcode updated early to revision 0x1f, date = 2018-02-07

> cd /sys/devices/system/cpu/vulnerabilities

> grep . *

meltdown: Mitigation: PTI

spectre_v1: Mitigation: __user pointer sanitization

spectre_v2: Mitigation: Full generic retpoline, IBPB

```

I haven't seen 'IBPB' before, so that seems to be the new flag to look for.

----------

## Ska`

 *mike155 wrote:*   

>  *Quote:*   I merged it and run emerge -e world adding -mindirect-branch=thunk -mfunction-return=thunk -fno-plt  
> 
> Why do you do this? Do you really think that your systems will be more secure or more reliable?
> 
> Look, there are many reasons why it makes sense to compile the kernel with retpoline and meltdown/spectre patches. The most important one is: because kernel developers know what they are doing, they tested it and they recommend it.
> ...

 

I agree and I wouldn't recommend that flags to a regular desktop user (that should follow the handbook and not a forum thread about new functionalities), I like to try new things and I reported that, at least the compiling, went almost fine.

I don't have time neither the knowledge to explain further but you can find what the flags are supposed to do, basically they drop the speculative execution support and most likely the only effect is a performance downgrade. You can start here from the 3rd post: https://forums.gentoo.org/viewtopic-t-1076300.html

----------

## Spargeltarzan

I have realised with one of the last kernel upgrades the Spectre v2 mitigation "improved" detected by the checker-tool

```

Spectre and Meltdown mitigation detection tool v0.35

Checking for vulnerabilities on current system

Kernel is Linux 4.14.28-gentoo #1 SMP Tue Mar 20 11:57:47 CET 2018 x86_64

CPU is Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Indirect Branch Restricted Speculation (IBRS)

    * SPEC_CTRL MSR is available:  YES 

    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)

  * Indirect Branch Prediction Barrier (IBPB)

    * PRED_CMD MSR is available:  YES 

    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)

  * Single Thread Indirect Branch Predictors (STIBP)

    * SPEC_CTRL MSR is available:  YES 

    * CPU indicates STIBP capability:  YES 

  * 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  (model 60 stepping 3 ucode 0x24)

* 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:  YES  (kernel confirms that the mitigation is active)

* Kernel has array_index_mask_nospec:  YES  (1 occurence(s) found of 64 bits array_index_mask_nospec())

* Kernel has the Red Hat/Ubuntu patch:  NO 

> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

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)

> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline, IBPB, IBRS_FW)

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

```

It reports not only full generic retpoline, but also IBPB and IBRS_FW in Spectre v2 now. But why the Mitigation 1 is on the other hand "NO", if IBPB and IBRS is available?

----------

## Ska`

 *Spargeltarzan wrote:*   

> It reports not only full generic retpoline, but also IBPB and IBRS_FW in Spectre v2 now. But why the Mitigation 1 is on the other hand "NO", if IBPB and IBRS is available?

 

As far as I understand, the new microcode supports IBPB and IBRS but the kernel not yet. I don't know what these mitigations are supposed to do and if it makes sense using them with retpoline.

----------

## Hossie

1: Skylake and later are not fully fixed with retpoline alone:

https://lwn.net/Articles/743019/

 *Quote:*   

> Speculation on Skylake and later requires these patches ("dynamic IBRS")
> 
> be used instead of retpoline[1].

 

2: IBRS is needed for KVM and guests that do not use retpoline, for example RHEL/CentOS. They depend on IBRS being available and passed through to the guest.

----------

## PrSo

AMD released microcode updates with mitigation against Spectre v2 which covers all CPU's since 2011 (Bulldozer family), but I wonder if it will be included in linux firmware package tough.

https://www.amd.com/en/corporate/security-updates

----------

## Tony0945

 *PrSo wrote:*   

> AMD released microcode updates with mitigation against Spectre v2 which covers all CPU's since 2011 (Bulldozer family), but I wonder if it will be included in linux firmware package tough.
> 
> https://www.amd.com/en/corporate/security-updates

 

Thanks for the heads up. How can we avoid these microcode updates?

----------

## Ant P.

If you don't want them, USE=savedconfig on linux-firmware can take care of that.

----------

## v_andal

Today I've tried to install gentoo-sources-4.4.95. It just refuses to boot on my PC. It freezes early in the boot process and I have to pull the plug, otherwise PC reacts to nothing. Now I guess I understand why newest Windows 10 does not work on my PC, most likely it has the same fixes and brings it to the same absolute freeze  :Smile: 

I've also tried to build kernel without new option, but it didn't help. So far I had to mask this version.

----------

## Tony0945

 *v_andal wrote:*   

> Today I've tried to install gentoo-sources-4.4.95. It just refuses to boot on my PC. It freezes early in the boot process and I have to pull the plug, otherwise PC reacts to nothing. Now I guess I understand why newest Windows 10 does not work on my PC, most likely it has the same fixes and brings it to the same absolute freeze 
> 
> I've also tried to build kernel without new option, but it didn't help. So far I had to mask this version.

 

I can boot 4.4.129 on my Bristol Ridge which is a bulldozer derivative.  I have not knowingly installed any microcode updates, although I have MSI's latest AM4 BIOS which may have installed some. It does seem slower than when I first got it. Is it the kernel?  Profile 17.0? Microcode? Or am I just getting used to the speed and wanting more? NO RETPOLINE or any other mitigation that I know of. The earlier kernels were dropped out of portage and I have heard (hear-say) that some kernel developers are bypassing instructions that would speed up but are Spectre vulnerable regardless of CONFIG settings. Another possibility is that Intel Meltdown vulnerabilities are patched even for AMD processors. After all, everyone uses Intel, don't they?

Try building 4.4.95 for a generic CPU. If that boots then possibly microcode has crippled your CPU.

----------

## NeddySeagoon

Tony0945,

If the Intel microcode update is being done by the kernel, it does not matter what CPU the kernel is built for.

The microcode updater identifies the CPU its running on and if there is an update it can apply, it does it.

Conversely, its enough to disable kernel microcode updating to test the theory.

----------

## steveL

 *Ant P. wrote:*   

> Everyone should have NoScript/uMatrix plus an adblocker at a bare minimum

  I totally agree, and have for years; but it bugs me, that there aren't at least 2 or 3 FLOSS browsers which do not give away any info, as a default.

----------

## Tony0945

 *NeddySeagoon wrote:*   

> Tony0945,
> 
> If the Intel microcode update is being done by the kernel, it does not matter what CPU the kernel is built for.
> 
> The microcode updater identifies the CPU its running on and if there is an update it can apply, it does it.
> ...

 

The main reason that I suggested building for generic was in case the kernel was using an opcode that the CPU hung on.

The rest of the post was just describing my setup that works with the later kernel. I may have had trouble with .75 also. I'm not sure. I know that at some fairly recent time I also blocked a kernel because it wouldn't build.

----------

## roki942

Intel Spectre-NG announced.

https://www.guru3d.com/news-story/eight-new-spectre-variant-vulnerabilities-for-intel-discovered-four-of-them-critical.html

https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html

edited to add 2nd link

----------

## ChrisJumper

And one more POC Code for Browsers and Spectre 1. alephsecurity - Overcoming (some) Spectre browser mitigations released a Paper and a javascript proof of concept Code for your Browser.

Right now just the mitigation in the firefox Browser work fine. It runs minutes here without a pair value.

On the stable chromium the poc work and deliver a functional working poc.

```
original value: 1100110011001100110011001100110

restored value: 1100110011001100110011001100110
```

Download poc as zip file. And open Spectre.html with your browser and its web developer Console to show the output of the javascript.

Shortcuts to open the console:

Firefox: ctrl + shift + j

Chromium: ctrl + shift + i

----------

## pjp

Continued in Meltdown/Spectre: Read Arbitrary Memory over Network.

----------

