On 1/22/2019 6:25 PM, Zelphir Kaltstahl wrote:
>> I disagree on one more point. It is not necessary to always remember >> the low level character of code running on a machine, if the language >> we are using abstracts it well and guarantees us, that there will not >> be strange effects in all the relevant cases for our programs. > > But a language CAN'T guarantee that there will not be effects - > "strange" or otherwise. Spectre attacks work even against code that > is correct WRT its programming language because languages either are > ignorant of - or are intentionally ignoring - side effects of those > fiddly little machine operations. That is a connection I do not fully understand. Spectre attack is something designed to break the system, or out of previously known bounds of what some code could do.
Spectre is a family of related attacks. They are not against the program per se, they are against the *hardware* - the CPU and/or the memory system of the computer. They (ab)use side effects of those fiddly little machine operations that you seem determined to ignore. Modern CPUs provide many information channels that can leak data from running programs if you know how to force them to do so.
Spectre attacks do not care what language was used to write the program, and they work against code which is perfectly correct at the language level.
There's a lot of very technical information out there, but a pretty good primer on the problem and explanation of the 1st discovered variant is at: https://spectreattack.com/spectre.pdf
Can such a thing happen unintentionally, when we write useful / constructive / productive / well meaning programs? I guess theoretically, but very very unlikely?
Last I looked there were over 100 known Spectre variants - exploiting various information channels in various and different ways - with researchers announcing one or more new variants each week.
I get that there is a chance of something having a strange effect, when the CPU is this kind of buggy (Intel cutting corners, still waiting for my free of charge sent replacement CPU, free from such bugs, being inserted in my machines for me by Intel :D), but that problem is on a lower layer of abstraction. If the language we use is in itself correct, isn't it then up to the lower layers to get things right? Afaik Spectre (or was that Meltdown?) are only possible, because of over optimistic branch prediction stuff (not an expert on such low level details at all, just from what I read online). Couldn't we construct hardware free of such mistakes? Or is there something fundamental, that will not allow that, so that we cannot ever have a language guaranteeing things?
You absolutely can construct a CPU that is resistant to Spectre: one such WAS called the 80486 and it was obsolete 25 years ago.
Branch prediction is only ONE variant of the problem - there are many others. And Intel is not unique in being vulnerable - Spectre affects chips from nearly every vendor, and in fact, it affects most chips on the market today.
Spectre vulnerability can't be designed out without either a radical rethink of CPU architecture (e.g., the Mill, which still is vaporware - https://millcomputing.com) or by returning to the [lack of] performance of designs from decades past.
Go poke around in comp.arch - they discuss Spectre rather frequently, and in more detail than you can imagine.
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
