3 ms·
I don't see anything preventing the OS, or the hypervisor on which the OS is running, from moving/copying the memory contents around to different physical pages
by cafxx 5y ago
I don't see anything preventing the OS, or the hypervisor on which the OS is running, from moving/copying the memory contents around to different physical pages, or potentially to swap or even over the network (e.g. for live migration).
This is obviously a step in the right direction, as it at least partially removes the JVM from the equation, but the devil is in the details and this by itself is not enough.
Also worth pointing out that, according to the docs, there is no guarantee that direct buffers are allocated outside the java GC heap:
> The contents of direct buffers may reside outside of the normal garbage-collected heap
https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffe...
A better alternative would be to actually mmap some memory for the buffer, and then use mlock/mprotect/madvise to prevent paging, unexpected accesses at the wrong time, and core dumps of sensitive materials. Still far from perfect, but already substantially better.
- java-man 5y agoYou are correct. DirectByteBuffer only guarantees that the memory will not be moved as a result of garbage collection, for example, when talking with native code. It does not prevent the OS from paging the whole memory block to disk, or writing it to a file in case of a VM saving its state. It's just marginally better than using plain primitive arrays, plus there is an extra method to explicitly clear the buffers via ICryptoZeroable, something that I think is missing from stock Bouncycastle.
- needusername 5y agomemfd_secret is probably what you want