Upvote Upvoted 30 Downvote Downvoted
1 2
Intel CPU Security Flaw
posted in Hardware
1
#1
ESEA
0 Frags +

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Looks like it affects pretty much all Intel CPUs. The patch to fix it will incur some kernel overhead so I'm guessing it will affect gaming/everyday performance at least a little bit.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Looks like it affects pretty much all Intel CPUs. The patch to fix it will incur some kernel overhead so I'm guessing it will affect gaming/everyday performance at least a little bit.
2
#2
2 Frags +

Cute website about the attack from the researchers: https://meltdownattack.com/

Basically, any program's memory can be read and tampered with, additional security *will* slow down processing (think of it like a military checkpoint on the road)
The overhead is estimated to be 20% to 30%

Cute website about the attack from the researchers: https://meltdownattack.com/

Basically, any program's memory can be read and tampered with, additional security *will* slow down processing (think of it like a military checkpoint on the road)
The overhead is estimated to be 20% to 30%
3
#3
5 Frags +

should I still do an intel build or is this big enough of an issue to do a ryzen build instead?

should I still do an intel build or is this big enough of an issue to do a ryzen build instead?
4
#4
4 Frags +
TwiiKuuCute website about the attack from the researchers: https://meltdownattack.com/

Basically, any program's memory can be read and tampered with, additional security *will* slow down processing (think of it like a military checkpoint on the road)
The overhead is estimated to be 20% to 30%

Its up to 50% in IO heavy server workloads. This is absolutely disastrous for Intel.

[quote=TwiiKuu]Cute website about the attack from the researchers: https://meltdownattack.com/

Basically, any program's memory can be read and tampered with, additional security *will* slow down processing (think of it like a military checkpoint on the road)
The overhead is estimated to be 20% to 30%[/quote]
Its up to 50% in IO heavy server workloads. This is absolutely disastrous for Intel.
5
#5
3 Frags +
-protoshould I still do an intel build or is this big enough of an issue to do a ryzen build instead?

i'd wait for benchmarks honestly, especially given how...optimized tf2 is

[quote=-proto]should I still do an intel build or is this big enough of an issue to do a ryzen build instead?[/quote]
i'd wait for benchmarks honestly, especially given how...optimized tf2 is
6
#6
4 Frags +
-protoshould I still do an intel build or is this big enough of an issue to do a ryzen build instead?

According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.

[quote=-proto]should I still do an intel build or is this big enough of an issue to do a ryzen build instead?[/quote]


According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.
7
#7
15 Frags +
springrollsi'd wait for benchmarks honestly, especially given how...optimized tf2 is

Correct.

In theory it shouldn't change much for TF2, although TF2 does weird shit with the TLB too so it could be either better or worse.
Generally games won't be affected much.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

In general though it is rather annoying and fucks filesystems completely.
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

TwiiKuuAccording to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.

Don't confuse Spectre and Meltdown.

Meltdown = fix is coming, but causes slowdown = Intel only
Spectre = everyone is fucked, but difficult to exploit = shown to work on Intel, only works on AMD within the same process or with specific non-default settings = no fix yet

[quote=springrolls]
i'd wait for benchmarks honestly, especially given how...optimized tf2 is[/quote]
Correct.

In theory it shouldn't change much for TF2, although TF2 does weird shit with the TLB too so it could be either better or worse.
Generally games won't be affected much.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

In general though it is rather annoying and fucks filesystems completely.
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

[quote=TwiiKuu]
According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.[/quote]
Don't confuse Spectre and Meltdown.

Meltdown = fix is coming, but causes slowdown = Intel only
Spectre = everyone is fucked, but difficult to exploit = shown to work on Intel, only works on AMD within the same process or with specific non-default settings = no fix yet
8
#8
0 Frags +
TwiiKuu-protoshould I still do an intel build or is this big enough of an issue to do a ryzen build instead?
According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.

It's affected by Spectre (but everything is affected by it, even though it's silly difficult to exploit).
Meltdown (the easy and rapey one) is Intel-specific.

[quote=TwiiKuu][quote=-proto]should I still do an intel build or is this big enough of an issue to do a ryzen build instead?[/quote]


According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.[/quote]
It's affected by Spectre (but everything is affected by it, even though it's silly difficult to exploit).
Meltdown (the easy and rapey one) is Intel-specific.
9
#9
-5 Frags +
TwiiKuu-protoshould I still do an intel build or is this big enough of an issue to do a ryzen build instead?
According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.

https://i.imgur.com/q2ri8JS.png

from what i read AMD is only seriously affected in the FX PRO niche series

[quote=TwiiKuu][quote=-proto]should I still do an intel build or is this big enough of an issue to do a ryzen build instead?[/quote]


According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.[/quote]
[img]https://i.imgur.com/q2ri8JS.png[/img]
from what i read AMD is only seriously affected in the FX PRO niche series
10
#10
11 Frags +

so can any1 whos a tech wiz put all this in laymans terms for us uneducated folk who r worried about our system security?

so can any1 whos a tech wiz put all this in laymans terms for us uneducated folk who r worried about our system security?
11
#11
3 Frags +

a friend told me to use this https://downloadcenter.intel.com/download/27150?v=t to check if my pc should be affected, can anyone confirm or deny if its a valid assessment?

a friend told me to use this https://downloadcenter.intel.com/download/27150?v=t to check if my pc should be affected, can anyone confirm or deny if its a valid assessment?
12
#12
6 Frags +
viper

in simple terms, this bug allows a program on a computer to access all of the memory on a computer without having to ask, meaning that it can see anything on your computer, including passwords, sensitive information, or anything else it might want. And because this is a hardware bug and not a software one, it affects literally everything with this hardware in it, including banking websites, google, amazon, or in short: everything. This means that an attacker can take any information that they want from anywhere that they want, and that's really really extraordinarily bad.

kaeos

that is unrelated to Meltdown or Spectre, the attacks in this thread. But it's never a bad idea to make sure that you aren't vulnerable to security holes, and if you are, how to mitigate them.

[quote=viper][/quote]

in simple terms, this bug allows a program on a computer to access all of the memory on a computer without having to ask, meaning that it can see anything on your computer, including passwords, sensitive information, or anything else it might want. And because this is a hardware bug and not a software one, it affects literally everything with this hardware in it, including banking websites, google, amazon, or in short: everything. This means that an attacker can take any information that they want from anywhere that they want, and that's really really extraordinarily bad.

[quote=kaeos][/quote]

that is unrelated to Meltdown or Spectre, the attacks in this thread. But it's never a bad idea to make sure that you aren't vulnerable to security holes, and if you are, how to mitigate them.
13
#13
1 Frags +

-

-
14
#14
tf2pickup.org
2 Frags +
barcaphilipso is performance always going to be worse now? or is it going to get back to normal?

It heavily depends on the application itself. After applying the software patch, the performance is worse for practically every system call (i.e. the really low-level kernel functions), as the user-space memory has to be explicitly separated from the kernel-space memory. So the performance impact will be seen mainly on servers (they use a lot of connect() syscall, for example). On client computers, it can be noticeable from time to time, but not during every-day use.

[quote=barcaphilip]so is performance always going to be worse now? or is it going to get back to normal?[/quote]
It heavily depends on the application itself. After applying the software patch, the performance is worse for practically every system call (i.e. the really low-level kernel functions), as the user-space memory has to be explicitly separated from the kernel-space memory. So the performance impact will be seen mainly on servers (they use a lot of connect() syscall, for example). On client computers, it [i]can[/i] be noticeable from time to time, but not during every-day use.
15
#15
2 Frags +

-

-
16
#16
tf2pickup.org
7 Frags +

What worries me the most, though, is that for ten years all the passwords, secret keys, etc. could be as well public. Technically, anybody could exploit any system, read all the secrets, all without any fingerprints or traces. I wonder how much NSA paid Intel for doing that.

What worries me the most, though, is that for ten years all the passwords, secret keys, etc. could be as well public. Technically, anybody could exploit any system, read all the secrets, all without any fingerprints or traces. I wonder how much NSA paid Intel for doing that.
17
#17
tf2pickup.org
2 Frags +
barcaphilipok thanks do you know when this patch is going to go live?

It is live for Linux already. I don't know when it's out for Windows, though.

[quote=barcaphilip]ok thanks do you know when this patch is going to go live?[/quote]
It is live for Linux already. I don't know when it's out for Windows, though.
18
#18
4 Frags +

Check whether your anti virus is compatible with Microsoft's patch, otherwise it may not be pushed out via Windows Update:

https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

Check whether your anti virus is compatible with Microsoft's patch, otherwise it may not be pushed out via Windows Update:

https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released
19
#19
3 Frags +

So where the fuck does it say which AVs are compatible?

So where the fuck does it say which AVs are compatible?
20
#20
3 Frags +
_segfaultWhat worries me the most, though, is that for ten years all the passwords, secret keys, etc. could be as well public. Technically, anybody could exploit any system, read all the secrets, all without any fingerprints or traces. I wonder how much NSA paid Intel for doing that.

It's not that easy, you still need the malicious code to be executed in the first place.

And I doubt the NSA was involved at all. They could never pay them enough to compensate for the effect this will have on their sales.

It was simply a design decision of "page faults will be thrown at retirement anyway so why bother checking?".
Intel probably never changed that because AMD patented the checking iirc and AMD only does it because it prevents bullshit data from being cached and is rather cheap, not because of security concern.

[quote=_segfault]What worries me the most, though, is that for ten years all the passwords, secret keys, etc. could be as well public. Technically, anybody could exploit any system, read all the secrets, all without any fingerprints or traces. I wonder how much NSA paid Intel for doing that.[/quote]
It's not that easy, you still need the malicious code to be executed in the first place.

And I doubt the NSA was involved at all. They could never pay them enough to compensate for the effect this will have on their sales.

It was simply a design decision of "page faults will be thrown at retirement anyway so why bother checking?".
Intel probably never changed that because AMD patented the checking iirc and AMD only does it because it prevents bullshit data from being cached and is rather cheap, not because of security concern.
21
#21
1 Frags +
the301stspartanSo where the fuck does it say which AVs are compatible?

I can understand why Microsoft don't want to disclose it, but some guy made a Google doc to track this information:

https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0

Other links to vendor KBs etc.
https://www.reddit.com/r/sysadmin/comments/7o2h3n/summary_of_useful_links_and_info_for/

[quote=the301stspartan]So where the fuck does it say which AVs are compatible?[/quote]

I can understand why Microsoft don't want to disclose it, but some guy made a Google doc to track this information:

https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0

Other links to vendor KBs etc.
https://www.reddit.com/r/sysadmin/comments/7o2h3n/summary_of_useful_links_and_info_for/
22
#22
1 Frags +

Remember that this only works around one vulnerability and more fixes should be coming which decrease performance slightly more.

EDIT: here's Intel's statement https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Remember that this only works around one vulnerability and more fixes should be coming which decrease performance slightly more.

EDIT: here's Intel's statement https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
23
#23
13 Frags +

That's just the usual trifecta of
"It's not a bug"
"Everyone got it"
"It's not as bad as you think"

For example

Intel believes these exploits do not have the potential to corrupt, modify or delete data.

actually means "yes you can read kernel data".

Right now the status is:
Variant 1 (Spectre/bounds check bypass):
Patchable, use conditionals instead of branches.
Relies on kernel-mode (so in the OS) interpreters or JITs executing the code so as soon as those are patched it's fixed.
May not even work with default configs on AMD.
Should not affect performance noticeably, especially if you're not using anything that's affected anyway.

Variant 2 (Spectre/branch target injection):
Patchable, don't use indirect jumps or prevent speculation on them or if possible invalidate the branch predictor on a context switch.
Depends on the specific branch predictor (CPU hardware). Intel Haswell has been proven to be affected and ARM says it also affects all Cortex cores. AMD claims theirs won't be vulnerable to it, but they are the only ones that actually know the inner workings of their hardware so it's difficult to verify.
The brute force patch Linux will use for now will affect performance, but I don't know by how much. Future patches might reduce the impact.

Variant 3 (Meltdown/rogue data cache load):
Patchable, flush TLB on every context switch.
Depends on the specific architecture. Might affect anything newer than the Pentium I from Intel (except Itanium and first gen Atom). According to ARM themselves only the Cortex-A75 is affected. AMD claims they are immune and so far it looks like it.
This is the one everyone is talking about. The performance impact depends on what you're doing. Pure number crunching won't see a noticeable change but for example file accesses will slow down rather significantly.
Unlike Spectre where multiple patches may still happen to close new security holes or to lessen the performance impact this will be more or less final. Unaffected CPUs may be added to whitelists later but if your is affected then it's going to stay like this.

That's just the usual trifecta of
"It's not a bug"
"Everyone got it"
"It's not as bad as you think"

For example
[quote]Intel believes these exploits do not have the potential to corrupt, modify or delete data.[/quote]
actually means "yes you can read kernel data".

Right now the status is:
Variant 1 (Spectre/bounds check bypass):
Patchable, use conditionals instead of branches.
Relies on kernel-mode (so in the OS) interpreters or JITs executing the code so as soon as those are patched it's fixed.
May not even work with default configs on AMD.
Should not affect performance noticeably, especially if you're not using anything that's affected anyway.

Variant 2 (Spectre/branch target injection):
Patchable, don't use indirect jumps or prevent speculation on them or if possible invalidate the branch predictor on a context switch.
Depends on the specific branch predictor (CPU hardware). Intel Haswell has been proven to be affected and ARM says it also affects all Cortex cores. AMD claims theirs won't be vulnerable to it, but they are the only ones that actually know the inner workings of their hardware so it's difficult to verify.
The brute force patch Linux will use for now will affect performance, but I don't know by how much. Future patches might reduce the impact.

Variant 3 (Meltdown/rogue data cache load):
Patchable, flush TLB on every context switch.
Depends on the specific architecture. Might affect anything newer than the Pentium I from Intel (except Itanium and first gen Atom). According to ARM themselves only the Cortex-A75 is affected. AMD claims they are immune and so far it looks like it.
This is the one everyone is talking about. The performance impact depends on what you're doing. Pure number crunching won't see a noticeable change but for example file accesses will slow down rather significantly.
Unlike Spectre where multiple patches may still happen to close new security holes or to lessen the performance impact this will be more or less final. Unaffected CPUs may be added to whitelists later but if your is affected then it's going to stay like this.
24
#24
1 Frags +

Also from the press release

IntelIntel believes its products are the most secure in the worldSetsulRelies on kernel-mode (so in the OS) interpreters or JITs executing the code so as soon as those are patched it's fixed.
May not even work with default configs on AMD.

JITs are common in some cases (ex. JavaScript), and don't have to be kernel level. Though, you are right about BPF JIT, which is disabled by default on Linux. Not sure if Windows has its own variant of this.

Also from the press release
[quote=Intel]Intel believes its products are the most secure in the world[/quote]

[quote=Setsul]Relies on kernel-mode (so in the OS) interpreters or JITs executing the code so as soon as those are patched it's fixed.
May not even work with default configs on AMD.[/quote]
JITs are common in some cases (ex. JavaScript), and don't have to be kernel level. Though, you are right about BPF JIT, which is disabled by default on Linux. Not sure if Windows has its own variant of this.
25
#25
2 Frags +

If Intel wanted to do something about Meltdown(or Spectre for that matter) on an architectural level, would they have to delay a product family like Ice Lake, or would there still be enough time to change it before tape-out if we assumed it would launch in say Q1 2019?

If Intel wanted to do something about Meltdown(or Spectre for that matter) on an architectural level, would they have to delay a product family like Ice Lake, or would there still be enough time to change it before tape-out if we assumed it would launch in say Q1 2019?
26
#26
2 Frags +
mastercomsJITs are common in some cases (ex. JavaScript), and don't have to be kernel level. Though, you are right about BPF JIT, which is disabled by default on Linux. Not sure if Windows has its own variant of this.

They don't have to be but that doesn't matter.
For the attack to work the executed code needs to be able access the data you want to leak. So if you're not in kernel mode an attack on the kernel will fail because the data is never accessed either a) because the permission check fails (AMD/ARM) or b) because the fix for Meltdown has already flushed the TLB and the adress isn't known.

Sure you can use it to gain access to data in your own process but that's a bit redundant. If your own program contains malicious code and uses it to leak its own data to itself, well, you've achieved nothing.
If you're running untrusted javascript code via JIT in the same process as some sensitive information you might want update your JIT to use conditional bound checks. On the other hand you're running untrusted javascript code via JIT in the same process as some sensitive information so you deserve everything that happens to you.

OsirisIf Intel wanted to do something about Meltdown(or Spectre for that matter) on an architectural level, would they have to delay a product family like Ice Lake, or would there still be enough time to change it before tape-out if we assumed it would launch in say Q1 2019?

Spectre isn't really fixable on an architectural level. Even in order cores are affected if the pipeline is long enough.
Ice Lake should have taped out by now. It's a matter of steppings and yields now. Changing when permissions are checked (before the loaded value appears vs at retirement) affects basically the whole CPU and at the point that Intel learned about the flaw they were most likely unable to change it. There's also the matter of AMDs patents so it might be quite a while before they fix it. If I'm correct it would be quite difficult to even get it into Tiger Lake (Ice Lake refresh). If they can still get it fixed on Sapphire Rapids, the architecture after that (2020+), which they are already working on because development takes ~4 years, then they might consider themselves lucky.

[quote=mastercoms]JITs are common in some cases (ex. JavaScript), and don't have to be kernel level. Though, you are right about BPF JIT, which is disabled by default on Linux. Not sure if Windows has its own variant of this.[/quote]
They don't have to be but that doesn't matter.
For the attack to work the executed code needs to be able access the data you want to leak. So if you're not in kernel mode an attack on the kernel will fail because the data is never accessed either a) because the permission check fails (AMD/ARM) or b) because the fix for Meltdown has already flushed the TLB and the adress isn't known.

Sure you can use it to gain access to data in your own process but that's a bit redundant. If your own program contains malicious code and uses it to leak its own data to itself, well, you've achieved nothing.
If you're running untrusted javascript code via JIT in the same process as some sensitive information you might want update your JIT to use conditional bound checks. On the other hand you're running untrusted javascript code via JIT in the same process as some sensitive information so you deserve everything that happens to you.

[quote=Osiris]If Intel wanted to do something about Meltdown(or Spectre for that matter) on an architectural level, would they have to delay a product family like Ice Lake, or would there still be enough time to change it before tape-out if we assumed it would launch in say Q1 2019?[/quote]
Spectre isn't really fixable on an architectural level. Even in order cores are affected if the pipeline is long enough.
Ice Lake should have taped out by now. It's a matter of steppings and yields now. Changing when permissions are checked (before the loaded value appears vs at retirement) affects basically the whole CPU and at the point that Intel learned about the flaw they were most likely unable to change it. There's also the matter of AMDs patents so it might be quite a while before they fix it. If I'm correct it would be quite difficult to even get it into Tiger Lake (Ice Lake refresh). If they can still get it fixed on Sapphire Rapids, the architecture after that (2020+), which they are already working on because development takes ~4 years, then they might consider themselves lucky.
27
#27
-3 Frags +
-protoshould I still do an intel build or is this big enough of an issue to do a ryzen build instead?

ethically probably not

[quote=-proto]should I still do an intel build or is this big enough of an issue to do a ryzen build instead?[/quote]

ethically probably not
28
#28
0 Frags +
SetsulThey don't have to be but that doesn't matter.
For the attack to work the executed code needs to be able access the data you want to leak. So if you're not in kernel mode an attack on the kernel will fail because the data is never accessed either a) because the permission check fails (AMD/ARM) or b) because the fix for Meltdown has already flushed the TLB and the adress isn't known.

Sure you can use it to gain access to data in your own process but that's a bit redundant. If your own program contains malicious code and uses it to leak its own data to itself, well, you've achieved nothing.
If you're running untrusted javascript code via JIT in the same process as some sensitive information you might want update your JIT to use conditional bound checks. On the other hand you're running untrusted javascript code via JIT in the same process as some sensitive information so you deserve everything that happens to you.

Not sure what the point of this response was, I wasn't trying to disagree with you that extensively, nor does your defense make sense. The possibility of browser exploitation should not be dismissed and the proper preventative measures should be taken to mitigate it. https://support.google.com/faqs/answer/7622138 (see Google Chrome listing)

[quote=Setsul]They don't have to be but that doesn't matter.
For the attack to work the executed code needs to be able access the data you want to leak. So if you're not in kernel mode an attack on the kernel will fail because the data is never accessed either a) because the permission check fails (AMD/ARM) or b) because the fix for Meltdown has already flushed the TLB and the adress isn't known.

Sure you can use it to gain access to data in your own process but that's a bit redundant. If your own program contains malicious code and uses it to leak its own data to itself, well, you've achieved nothing.
If you're running untrusted javascript code via JIT in the same process as some sensitive information you might want update your JIT to use conditional bound checks. On the other hand you're running untrusted javascript code via JIT in the same process as some sensitive information so you deserve everything that happens to you.[/quote]
Not sure what the point of this response was, I wasn't trying to disagree with you that extensively, nor does your defense make sense. The possibility of browser exploitation should not be dismissed and the proper preventative measures should be taken to mitigate it. https://support.google.com/faqs/answer/7622138 (see Google Chrome listing)
29
#29
0 Frags +

I wasn't sure where you were going with pointing out that JITs exist outside of the kernel.

Well I wanted to point out the difference between the "shit's on fire" situation that is leaking kernel data from userspace with default configs (Intel) or non-default config or a more sophisticated variation (AMD) and the eternal dumpster fire that is browser security with javascript. Because the former will be fixed soon, the latter will only be fixed when javascript etc. are running in a seperate process. That's the reason why that feature exists.
On second though if this is what it takes to make site isolation the default then sure, go ahead and warn as many as you can.

I wasn't sure where you were going with pointing out that JITs exist outside of the kernel.

Well I wanted to point out the difference between the "shit's on fire" situation that is leaking kernel data from userspace with default configs (Intel) or non-default config or a more sophisticated variation (AMD) and the eternal dumpster fire that is browser security with javascript. Because the former will be fixed soon, the latter will only be fixed when javascript etc. are running in a seperate process. That's the reason why that feature exists.
On second though if this is what it takes to make site isolation the default then sure, go ahead and warn as many as you can.
30
#30
2 Frags +

So this is what ESEA has been using after the Bitcoin fiasco

So this is what ESEA has been using after the Bitcoin fiasco
1 2
Please sign in through STEAM to post a comment.