Why memset_s and Annex K in general is an utterly stupid idea: https://gcc.gnu.org/ml/gcc-help/2014-10/msg00071.html …
-
-
Replying to @RichFelker
Scrubbing sensitive data requires compiler-level features, not magical "don't 'optimize out' this memset" gimmicks.
2 replies 0 retweets 0 likes -
Replying to @RichFelker
.
@RichFelker yes, it needs a way to mark data/structures as sensitive, and have the compiler automatically clean the data from unused locs.1 reply 0 retweets 0 likes -
Replying to @encthenet
@encthenet That's the ideal "blacklist" solution, but it's still very hard to get right at the compiler level.1 reply 0 retweets 1 like -
Replying to @RichFelker
@encthenet The real solution is a whitelist approach: abolish the practice of fork/setuid-and-keep-going. It's insecure for so many reasons.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@encthenet The whitelist approach is to always execve after using sensitive information, and only pass on what's needed.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker You still need the compiler to not do stupid things with the keys. You just can't write guaranteed secure code without marks.1 reply 0 retweets 0 likes
@encthenet I believe obliterating the VM space with _exit or execve addresses the threat model most people are interested in.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.