Page 1 of 1

SSB: Yet another security hole due to speculative execution

Posted: Tue 22 May 2018, 21:32
by prehistoric
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.

Posted: Sun 27 May 2018, 19:20
by 8Geee
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

Posted: Wed 30 May 2018, 11:58
by ozsouth
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.

Posted: Mon 04 Jun 2018, 15:15
by backi
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 ?

Posted: Wed 20 Jun 2018, 07:06
by rufwoof
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.

cache vulnerability without speculative execution

Posted: Sun 24 Jun 2018, 14:43
by prehistoric
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.