Hi! > >> > What remains to be seen is if there are other patterns that affect > >> > different processors. > >> > > >> > In the longer term the compiler itself needs to know what is and isn't > >> > safe (ie you need to be able to write things like > >> > > >> > void foo(tainted __user int *x) > >> > > >> > and have the compiler figure out what level of speculation it can do and > >> > (on processors with those features like IA64) when it can and can't do > >> > various kinds of non-trapping loads. > >> > > >> > >> It would be great if coccinelle and/or smatch could be taught to catch > >> some of these case at least as a first pass "please audit this code > >> block" type of notification. > >> > > > > What should one be looking for. Do you have a typical example? > > > > See "Exploiting Conditional Branch Misprediction" from the paper [1]. > > The typical example is an attacker controlled index used to trigger a > dependent read near a branch. Where an example of "near" from the > paper is "up to 188 simple instructions inserted in the source code > between the ‘if’ statement and the line accessing array...". > > if (attacker_controlled_index < bound) > val = array[attacker_controlled_index]; > else > return error; > > ...when the cpu speculates that the 'index < bound' branch is taken it > reads index and uses that value to read array[index]. The result of an > 'array' relative read is potentially observable in the cache. You still need (void) array2[val]; after that to get something observable, right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
