| View previous topic :: View next topic |
| Author |
Message |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
 Posted: Sun Jan 14, 2018 12:54 am Post subject: |
 |
|
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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
 |
mno
Guru
Joined: 29 Dec 2003
Posts: 454
Location: Toronto, Canada
|
| Posted: Sun Jan 14, 2018 12:56 am Post subject: |
|
|
| 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?
_________________
"Hello and goodbye. As always." | You can't use here?? | Unanswered |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
|
| Back to top |
|
|
mno
Guru
Joined: 29 Dec 2003
Posts: 454
Location: Toronto, Canada
|
| Posted: Sun Jan 14, 2018 1:01 am Post subject: |
|
|
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!
_________________
"Hello and goodbye. As always." | You can't use here?? | Unanswered |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Sun Jan 14, 2018 1:06 am Post subject: |
|
|
Several days ago, pjp put it in the first post of the thread. Does that count?  |
|
| Back to top |
|
|
gengreen
Apprentice
Joined: 23 Dec 2017
Posts: 150
|
| Posted: Sun Jan 14, 2018 1:08 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Sun Jan 14, 2018 1:44 am Post subject: |
|
|
| 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
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Sun Jan 14, 2018 4:05 pm Post subject: |
|
|
| 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 there is a function:
| Code: | 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. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Sun Jan 14, 2018 8:00 pm Post subject: |
|
|
| 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 ? |
|
| Back to top |
|
|
noci2
n00b
Joined: 14 Jan 2018
Posts: 10
|
| Posted: Sun Jan 14, 2018 9:05 pm Post subject: |
|
|
| 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)
> 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<-- |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Sun Jan 14, 2018 9:13 pm Post subject: |
|
|
| 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 :
| Quote: | 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 |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Jan 14, 2018 10:07 pm Post subject: |
|
|
| 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 :
| Quote: | 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
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Sun Jan 14, 2018 10:51 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Sun Jan 14, 2018 11:02 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Sun Jan 14, 2018 11:10 pm Post subject: |
|
|
| 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 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. |
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. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Sun Jan 14, 2018 11:53 pm Post subject: |
|
|
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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2963
Location: Edge of marsh USA
|
| Posted: Mon Jan 15, 2018 12:26 am Post subject: |
|
|
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.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Mon Jan 15, 2018 12:47 am Post subject: |
|
|
| 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 | Code: | | sudo taskset 0x1 ./kaslr |
it took about 20 minutes to guess the address. (one cpu core was 100% utilized),
and then | Code: | | 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. |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Mon Jan 15, 2018 12:55 am Post subject: |
|
|
when you are using a race condition to launch a microarchitectural attack there will be some inconsistency.  |
|
| Back to top |
|
|
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000
|
| Posted: Mon Jan 15, 2018 1:46 am Post subject: |
|
|
PoC that needs root privileges to work, I don't get that  |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Mon Jan 15, 2018 1:47 am Post subject: |
|
|
| kajzer wrote: | | PoC that needs root privileges to work, I don't get that |
u can't just give it away to the scriptkidz |
|
| Back to top |
|
|
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000
|
| Posted: Mon Jan 15, 2018 2:13 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Mon Jan 15, 2018 2:21 am Post subject: |
|
|
| 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.
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. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 15, 2018 4:41 am Post subject: |
|
|
| 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): | Code: | 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!)
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 15, 2018 5:00 am Post subject: |
|
|
| 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 |
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?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
Kernel & Hardware
