I don't believe in any solution to this problem and won't attempt it. Don't bother trying. In fact, see Abigail-II's comments. In theory this is something you can do in C but some discussions on sec-prog lead me to think that it may be difficult to impossible to reliably remove something from memory because the compiler is handy at optimizing away these "useless" optimizations. I recall both MSVC and gcc were under discussion. | [reply] |
To do it right, you need a patch to perl's Perl_sv_clear to wipe the PV buffer, and you need to make sure you don't keep any pads around longer than necessary (by freeing the code that used them). Even so, you are only shortening the window that sensitive data is accessible via /dev/mem. If it's all that sensitive, it's hard to see how that could be good enough.
| [reply] |
No, I had two points neither of which I elaborated. The first is that perl is likely going to find all sorts of funny places to copy the data and I wonder how likely it is to find all of them. I also wonder, does the current implementation of perl call sv_free at the proper time to support the wishes of the requestor? There's that pesky difference between something going out of scope-being-freed and the actually, really being freed, perhaps after having undef() called on it. The second point is that anything that attempts to clear the memory is going to have to do something compiler/version specific to hint to that the otherwise useless operation has a side effect and that it shouldn't be optimized away. You could consider it this way - some compilers take something like sub foo { my $bar = 1; return 0 }, notice that the my $bar = 1 doesn't affect anything else and just eliminate it. That'd be C code though so the perl is just an example. I don't speak C well enough to produce a proper example.
| [reply]
[d/l]
[select] |