Hacker News new | comments | show | ask | jobs | submit login

Of course if RdRand is aware of how it is to be used and looks at the place it is supposed to be XORed with, then including it would hurt.

But it would need to be actively aware of what is where in memory to do this.




Yes, sure, that's a possibility. You could imagine a situation where a microcode update to the Intel processor is written to modify RdRand in the knowledge of specific Linux versions and it would alter the values being returned because it would be aware of where it is used. You might even imagine some cleverness that actually alters the surrounding program's execution.

In a past life I did stuff like this where a device driver actually modified a running program to patch it to fix bugs/compatibility. It's not a complete fantasy to imagine that this might be possible.

But, hey, it's software. Anything possible; with computers it's best to look for what's likely, not what's possible.


But, hey, it's software. Anything possible; with computers it's best to look for what's likely, not what's possible.

When it comes to security, this is a horrible assumption.

It is the nature of the game that an attacker should be expected to use whatever piece that they control in the most malicious way possible. Thus if it is possible, and they are motivated, then you should never assume that they wouldn't do that. Because push comes to shove, why wouldn't they?

And if you're wrong, well, a little paranoia never hurt anyone. Particularly since in this case exercising paranoia is a simple matter of mixing in hardware randomness BEFORE doing all of the other complicating stuff, as opposed to the current order of doing all of the other complicating stuff AND THEN grabbing from potentially untrustworthy hardware that could be playing tricks.


Thus if it is possible, and they are motivated, then you should never assume that they wouldn't do that. Because push comes to shove, why wouldn't they?

That's sort of my point. "Push comes to shove" -> they'll do the easy thing first.


And when the easy thing does not work, they go one step farther.

If their goal is to target Linux, and they know what Linux code looks like, why not take it one step farther?


This can be done far more simply in hardware. Simply look at the instruction decode pipeline, and XOR with the operand of the next instruction that consumes your return value to bias the result.


Backdooring the XOR instruction would be far more useful.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: