Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

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

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:Se ... nd_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]

I guess this should be stickied somewhere but oh well, not a problem to keep posting it...
https://wiki.gentoo.org/wiki/Project:Se ... nd_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?

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

IMPORTANT:
A false sense of security is worse than no security at all.

Loved it.

[eccerr0r]

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]

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

It can be enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y

the default PTI state during boot is set to "auto", and in

Code: Select all

arch/x86/mm/ptic.c

there is a function:

Code: Select all

 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]

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)
> STATUS: VULNERABLE [/code]

I wonder if that's a side effect of Gentoo kernels not compiling in thousands of useless drivers. Maybe we're fine there.

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]

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 :

IMPORTANT:
A false sense of security is worse than no security at all.

Loved it.

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]

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 :

IMPORTANT:
A false sense of security is worse than no security at all.

Loved it.

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

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]

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

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]

Part of me groaned when that "checker" was being used around this place

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]

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

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.

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]

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

Code: Select all

sudo taskset 0x1 ./kaslr

it took about 20 minutes to guess the address. (one cpu core was 100% utilized),
and then

Code: Select all

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.

[The Main Man]

PoC that needs root privileges to work, I don't get that

[blopsalot]

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]

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]

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.

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]

That sounds to me like CONFIG_PAGE_TABLE_ISOLATION should be enabled for AMD processors. Or at least not setting it with the knowledge of leaving the vulnerability exposed.

So it seems that even if you compile kernel with CONFIG_PAGE_TABLE_ISOLATION=Y PTI is auto-disabled on AMD cpu anyway.

But the underlying issue is still whether or not AMD should have it enabled. From the prior information, the answer appears to be yes.

To enable the functionality, I had to enable the kernel option AND enable it on the kernel command line with "pti=on". After that (and only after that):

Code: Select all

 dmesg |grep -i isol
[    0.000000] Kernel/User page tables isolation: force enabled on command line.
[    0.000000] Kernel/User page tables isolation: enabled

(I got the idea from Naib's post on page 5 of this thread which referenced "pti=off". Thanks Naib!)

[pjp]

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

Exactly...

Part of me groaned when that "checker" was being used around this place... it just checks the main mitigations are in-place. This in itself is a good check BUT if you really want to be sure you need to run the PoC code

What makes random C code on github which requires root access trustworthy?

But to write a PoC and need that.... maybe I got things wrong but I thought the whole point of this exploits/bugs is that you can read kernel memory from userland, reading it from root ... I don't see a point.

Well, isn't one of the primary warnings to not run untrustworthy code?