As it's directly related to my work I have to deal with this, with or without adjectives...
Speculative execution can be applied without our knowing to parts of our apps so as to leverage spare CPU cycles that exist between memory reads/writes, thus speeding up our Apps execution by 5-30%. This is done efficiently though a special memory model which reportedly can be compromised by attackers to (eventually) obtain all of a system's secret data (i.e. root access).
Why I'm saying this SPOILER will probably become OUR problem to deal with too, is because we are the ones who write the high-level branch subject to involuntary speculative execution even though most of us (including me) are not or only barely aware of the lower level programming this involves on Intel's chips. For example, in 2015 Paul Lefebvre in his Xojo blog post "Tips: Dealing with the Problem of Passwords" summarised the program flow, which notably is coded by us not only the OS vendors:
To validate that the password is correct, when the user logs in you calculate the hash of the password they entered and then check to see if it matches the hash of the password you have stored. If they are the same then you know the password is correct even though you do not know the actual password.
...use a “salt” along with the password to create the hash. The salt is an extra value that you add to the password to generate hashes that make rainbow tables largely useless. You can use the same salt value for all the passwords or you can use something more specific for each password.
Moreover in 2012 Chris Musty responded to the RealSoftware blog "Dealing with the Problem of Passwords" saying:
Every time a user logs in, a random salt should be generated and appended (prefixed, jumbled whatever) to the password before being hashed. Storing the hash AND the salt separately in the database (or even a readable text file) makes it easy to validate the user but extremely hard to crack.
Admittedly none of his matters if an attacker eventually gets root access to a system but that is not guaranteed. So my argument is if we wrote the code handling passwords in user space most likely we will be the ones needed to modify it; if we write code like this pseudo:
strPasswordHash = SHA512(strPassword + strSalt)
If strStoredHash = strPassWordHash then
// Let user continue with program
//Tell user to go away
then maybe we are the ones (i.e. not just Microsoft, Linus Torvalds et al or Apple) who are implementing the " control flows that are dependent on the data of interest" that Intel is talking about. Maybe this problem needs to be solved in XojoLand (i.e. in non-privileged User Space controlled by us and the language-compiler) and not in the kernel, since it is the structure of our code that triggers the (apparently automatic) speculative execution in hardware seemingly largely beyond kernel developer' control...
So where are we then? The aforementioned blog in 2012 rightly considered database security thus:
The best way to not allow passwords to be compromised is to not store the password at all. Unfortunately, I've seen far too many apps that have databases with a "password" column that contains the actual password!
I think due to the vulnerabilities of speculative execution - which may well be good for things like speeding up loops but not-so-good for verifying authentications - the time has come to extend that time-honoured principle to salted hashes that are presently stored in memory. May I propose avoiding using salted hashes in branch execution such as If/Then and loops, by instead generating Booleans from them, then feeding a Boolean to the branch for comparison. Thus the pseudo code becomes something like:
Function BitwiseStringComparison ( memPasswordHash, memStoredHash) as Boolean
if memPasswordHash.Size = memStoredHash.Size Then
intComparator = memPasswordHash.IntegerValue(intOffset) XOR memStoredHash.IntegerValue(intOffset)
offset = offset + 1
if intComparator <> 0 or or intOffset = memPasswordHash.Size then
If intComparator = 0 Then
memPasswordHash = SHA512(memPassword + memSalt)
boolPaswordIsCorect = BitwiseStringComparison ( memPasswordHash, memStoredHash)
//Speculative execution block starts here?
If boolPasswordIsCorrect = TRUE then
// Let user continue with program
//Tell user to go away
The branching in this pseudo code is performed on a Boolean or integers, and not such "control flows that are dependent on the data of interest" as Intel would put it. I've no way to test if this works of course, but having read the researchers' paper I see no reason to suppose why an assignment made before a branch should form part of speculative execution memory. I base this on my reading of the researchers' paper which states:
...if the stores are committed before the victim’s speculative load,there will be no dependency resolution hazard.
This comment seems consistent with Intel's reported response that there exist "side channel safe development practices" (of which there 's precious little information out there I could find - sounds like PR to me).
So as I understand it from an application programmer's standpoint, speculative execution may cause my pseudo code's TRUE branch to run in potentially vulnerable privileged memory before the BitwiseStringComparison return is fetched. However the call to memory to check the function's return will now be to a boolean value not the stored hash value. But if this be so, I'm still left wondering how far down the branch will other variables containing sensitive information be loaded into potentially leaky speculative execution? If Speculative Execution starts with 'If' does it end with 'End', or sometime sooner?