Love4Boobies wrote:
Passwords shouldn't be in memory to begin with. Even when reading them in, you should be using a secure interface or, if you can't, at the very least minimize the risk of something going wrong by reading one character at a time and passing it through a one-way hash of some kind, which would allow for incremental computing.
I agree... That is why I mentioned the Tresor project in my next post... basically encryption/decryption happens in the cpu registers without a memory footprint.
There is also a wonderful concept known as "Cache as RAM" which effectively uses cache... as RAM; again allowing encryption/decryption to happen without a memory footprint.
zenzizenzicube mentioned he has his own kernel, therefore either of these options is available to him and presumably he has control over paging.
While for userspace there are a significant number of tools for such things as taint analysis, binary analysis of just what is actually produced by the compiler is lacking. A few llvm projects work on bit-code but do not deal with actual object code generation.
However, for the adventurous there is the combination of the CompCert C Compiler and (as mentioned before, Frama-C)
http://compcert.inria.fr/compcert-C.htmlhttp://frama-c.com/In combination, you would use Frama-C to validate pre/post conditions and even your memory image pre/post conditions, inject applicable asserts(), etc... to verify your kernel actually does what you specified in your security assumptions.
Then compile actual object code using the CompCert C compiler - which is formally proven (they say) to produce object code that does exactly what the input C code described.
Together these would be a dream if only CompCert produced x86-64 code...
oh well