Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

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

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]

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.

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/Microsof ... ation.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."

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]

But the program segfaults if I try to read directly from it...?

How are you reading the memory?

Code: Select all

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.

Code: Select all

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

Code: Select all

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

Code: Select all

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]

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/u ... idance.pdf
https://www.supermicro.com/support/secu ... -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]

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?

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]

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]

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-re ... ault.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]

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]

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]

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]

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]

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.

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:

Code: Select all

/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]

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]

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

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]

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:

1. The program relies on undefined behavior.
2. 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:

Code: Select all

   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:

Code: Select all

$ 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:

Code: Select all

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:

Code: Select all

 * Okay, okay, this is not the fastest code - improvements are welcome.

The code might go faster if it was compiled with all standard optimizations.

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.

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.

[mike155]

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:

Code: Select all

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

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.

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

Code: Select all

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

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.