Just when you thought you might be able to trust the hardware you are running, after patching for Meltdown, Specter and variants, there is a new exploit named SSB that finds timing differences caused by storing results of speculative execution.
The problem comes from fetching things before you can be sure of the address. If the predicted address is wrong, the natural fix is to dump the fetched data as invalid. Unfortunately, this still means you can get data from addresses that should be forbidden to a process into a register available to the microarchitecture, but not in the idealized machine model. Once there the difference in the time required for operations allows data to leak to processes that should never have had it. If you didn't have cores performing billions of instructions per second I don't think this would be very practical, because of the low bandwidth channel it offers into other processes.
Only a determined paranoid would have guessed this one.
SSB: Yet another security hole due to speculative execution
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
SSB: Yet another security hole due to speculative execution
Last edited by prehistoric on Sun 24 Jun 2018, 14:47, edited 1 time in total.
This is evidently a serious "inter-cache" problem. kernnel dot org as of May 25 updates is patching some flaws related. As usual this will be on-going. As I read it, it appears that a single cache split between data and info is also affected. Some Intel MPU/CPU have this split-cache, including a few ATOMS (the E600 series).
Regards
8Geee
Regards
8Geee
Linux user #498913 "Some people need to reimagine their thinking."
"Zuckerberg: a large city inhabited by mentally challenged people."
"Zuckerberg: a large city inhabited by mentally challenged people."
From http://www.theregister.co.uk/2018/05/21 ... ft_google/
According to Intel, mitigations already released to the public for variant 1, which is the hardest vulnerability to tackle, should make attacks leveraging variant 4 much more difficult. In other words, web browsers, and similar programs with just-in-time execution of scripts and other languages, patched to thwart variant 1 attacks should also derail variant 4 exploits.
According to Intel, mitigations already released to the public for variant 1, which is the hardest vulnerability to tackle, should make attacks leveraging variant 4 much more difficult. In other words, web browsers, and similar programs with just-in-time execution of scripts and other languages, patched to thwart variant 1 attacks should also derail variant 4 exploits.
Hi !
Bodhi Linux shut down Distribution`s Forum due GDPR :
https://www.bodhilinux.com/2018/06/03/f ... e-to-gdpr/
https://www.eugdpr.org/
See also Distrowatch :
https://distrowatch.com/weekly.php?issue=20180604#news
I am no Expert ....what are the Consequences ......could PuppyLinux Forum also be affected ?
Bodhi Linux shut down Distribution`s Forum due GDPR :
https://www.bodhilinux.com/2018/06/03/f ... e-to-gdpr/
https://www.eugdpr.org/
See also Distrowatch :
https://distrowatch.com/weekly.php?issue=20180604#news
I am no Expert ....what are the Consequences ......could PuppyLinux Forum also be affected ?
Since it is a security risk OpenBSD have opted to disable Intel's hyperthreading by default https://www.mail-archive.com/source-cha ... 99141.html and opine that generally the performance hit can be low, if any ...
Note that SMT doesn't necessarily have a positive effect on performance;
it highly depends on the workload. In all likelihood it will actually slow down most workloads if you have a CPU with more than two cores.
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
cache vulnerability without speculative execution
We have several different topics in this thread, like the GDPR, which belong in separate topics.
What I'm adding to this is a mention of a new vulnerability in Intel processors due to caches used to implement hyperthreading. It does not depend on speculative execution, but it does use a timing side channel. Modern Intel processors have two complete sets of registers in the microarchitecture to hold state for rapid context switches. This exploit allows information to leak from one to the other.
At this point it does not seem to apply to AMD processors and their hypertransport which is a very different machine model from hyperthreading that does not give programmers the appearance of multiple processors. Only the "hyper" prefix seems to connect these architectures.
So far it appears that the OS would have to be infected with malware to make this possible. Once this happens malware could grab cryptographic keys used for things like HTTPS. Disabling hyperthreading will defeat this.
What I'm adding to this is a mention of a new vulnerability in Intel processors due to caches used to implement hyperthreading. It does not depend on speculative execution, but it does use a timing side channel. Modern Intel processors have two complete sets of registers in the microarchitecture to hold state for rapid context switches. This exploit allows information to leak from one to the other.
At this point it does not seem to apply to AMD processors and their hypertransport which is a very different machine model from hyperthreading that does not give programmers the appearance of multiple processors. Only the "hyper" prefix seems to connect these architectures.
So far it appears that the OS would have to be infected with malware to make this possible. Once this happens malware could grab cryptographic keys used for things like HTTPS. Disabling hyperthreading will defeat this.