Jeremy Chadwick wrote:
It's interesting that you classified this as a "feature" (in quotes),
because there's nothing "modern" about said "feature". This issue has
existed since the beginning of RAM chip engineering; I can even confirm
this "feature" exists on old video game consoles such as the Nintendo
and Super Nintendo (where there were strict guidelines put in place by
Nintendo, requiring developers to initialise certain areas of memory
and certain memory-mapped I/O registers during hard or soft resets).
I shouldnt've used the word 'modern', then.
Proper software should be memset() or bzero()'ing memory space it
mallocs. I've gotten in the habit of doing this for years, purely as a
safety net. If said software doesn't do this, it's very likely
succeptable.
That is not relevant to the issue. The issue is that the keys are in
memory when the encrypted filesystem is in use. The keys can be read by
pulling and reinserting the power plug and restarting into a tool that
can dump memory (or by placing the memory modules in another system).
The keys to encrypted volumes can be found in this dump, leading to a
compromise of the data.
--
Pieter
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
