| View previous topic :: View next topic |
| Author |
Message |
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1172
Location: /run/user/1000
|
 Posted: Fri Jan 05, 2018 6:15 pm Post subject: |
 |
|
| 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. |
|
| Back to top |
|
 |
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Fri Jan 05, 2018 6:20 pm Post subject: |
|
|
| 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
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Fri Jan 05, 2018 6:45 pm Post subject: |
|
|
| 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:
| Code: | | AMD Opteron 62xx class CPU |
|
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:
| Code: | ./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. |
|
| Back to top |
|
|
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1172
Location: /run/user/1000
|
| Posted: Fri Jan 05, 2018 6:50 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Fri Jan 05, 2018 8:04 pm Post subject: |
|
|
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.
_________________
Beware the grue. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Jan 05, 2018 8:05 pm Post subject: |
|
|
Stop playing words...
| Naib wrote: | There is no whitelist of CPU's, the present RC has a blunt arch check.
| Code: | + /* Assume for now that ALL x86 CPUs are insecure */
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE |
|
A blacklist
| Quote: | | Code: | + if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE); |
|
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. |
|
| Back to top |
|
|
sligo
Tux's lil' helper
Joined: 17 Oct 2011
Posts: 93
|
| Posted: Fri Jan 05, 2018 8:40 pm Post subject: |
|
|
| 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:
| Code: | | AMD Opteron 62xx class CPU |
|
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:
| Code: | ./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. |
I've just tried that on that unpatched AMD server and a Intel system with patched kernel. On both, i got the same output:
| Code: | | 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. |
|
| Back to top |
|
|
yamabiko
n00b
Joined: 22 Jul 2017
Posts: 10
|
| Posted: Fri Jan 05, 2018 9:14 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2754
Location: Here and Away Again
|
| Posted: Fri Jan 05, 2018 9:15 pm Post subject: ><)))°€ |
|
|
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
| Code: | 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.
*/ |
_________________
Kindest of regardses. |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Fri Jan 05, 2018 9:19 pm Post subject: |
|
|
| 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.
_________________
Beware the grue. |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Fri Jan 05, 2018 9:32 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
yamabiko
n00b
Joined: 22 Jul 2017
Posts: 10
|
| Posted: Fri Jan 05, 2018 9:43 pm Post subject: |
|
|
| 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) |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Fri Jan 05, 2018 9:56 pm Post subject: |
|
|
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.
_________________
Beware the grue. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9891
Location: almost Mile High in the USA
|
| Posted: Fri Jan 05, 2018 10:02 pm Post subject: |
|
|
Any predictions what will be the stable gentoo-sources that will contain the PTI change?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Spargeltarzan
Guru
Joined: 23 Jul 2017
Posts: 328
|
| Posted: Fri Jan 05, 2018 10:19 pm Post subject: |
|
|
What exatly will be the role of the new microcode intel-microcode-20171117_p20171215? I thought with microcode loading it is not fixable?
_________________
___________________
Regards
Spargeltarzan
Notebook: Lenovo YOGA 900-13ISK: Gentoo stable amd64, GNOME systemd, KVM/QEMU
Desktop-PC: Intel Core i7-4770K, 8GB Ram, AMD Radeon R9 280X, ZFS Storage, GNOME openrc, Dantrell, Xen |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9891
Location: almost Mile High in the USA
|
| Posted: Fri Jan 05, 2018 10:23 pm Post subject: |
|
|
It disables a feature that is necessary by spectre.
_________________
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
|
|
| Back to top |
|
|
Pearlseattle
Apprentice
Joined: 04 Oct 2007
Posts: 165
Location: Switzerland
|
| Posted: Fri Jan 05, 2018 10:36 pm Post subject: "gentoo-sources" package: versions fixed against & |
|
|
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 
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...
| Code: | | 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...
| Code: | | 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:
| Code: | 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  .
Cheers!
Edit 6.Jan.2018 02:20 CET
Dropped email to "Alice" (Gentoo kernel maintainer). |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Fri Jan 05, 2018 11:40 pm Post subject: |
|
|
| 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.
| Code: |
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.
|
_________________
Beware the grue. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9891
Location: almost Mile High in the USA
|
| Posted: Fri Jan 05, 2018 11:47 pm Post subject: |
|
|
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?)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23093
|
| Posted: Sat Jan 06, 2018 12:10 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Sat Jan 06, 2018 12:15 am Post subject: |
|
|
| 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.
| Code: |
--- 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 */
|
_________________
Beware the grue. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9891
Location: almost Mile High in the USA
|
| Posted: Sat Jan 06, 2018 12:53 am Post subject: |
|
|
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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Sat Jan 06, 2018 1:01 am Post subject: |
|
|
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.
_________________
Beware the grue. |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 498
Location: Gainesville, FL, USA
|
| Posted: Sat Jan 06, 2018 5:10 am Post subject: |
|
|
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: | Code: | | grep ' pcid ' /proc/cpuinfo |
If you see any output when you run this, your processor has the feature. |
|
| Back to top |
|
|
|
Kernel & Hardware
