<div dir="ltr">What interests me, beyond what "the allocator" does, is what happens when a process's heap is garbage collected.<br>To take a more specific example - let's say I have a sensitive small binary, e.g. a credit card number. Though there should be little to no real risk from memory snoopers, I'd like the memory space it would have occupied to have been cleared when I'm done with it - i.e., zero out free space after GC. This would make me feel a bit more secure in the face of third-party modules (though yes, port programs are the preferred way to go).<br>
<br><br><br><div class="gmail_quote">On Thu, Apr 28, 2011 at 12:07 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf.wiger@erlang-solutions.com">ulf.wiger@erlang-solutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div><div>I think a good starting point is to meditate over this page:</div><div><a href="http://www.erlang.org/doc/man/erts_alloc.html" target="_blank">http://www.erlang.org/doc/man/erts_alloc.html</a></div>
<div><br></div><div>It seems to me that it would be _possible_ (with some work) to make use of the +Mym flag, substituting another malloc library for libc. In the old days, with non-SMP Erlang, this was entirely doable, and we played around with different allocators in the AXD 301 project, in order to see which one gave the least fragmentation over time.</div>
<div><br></div><div>The whole memory management subsystem in BEAM has become a *lot* more sophisticated since then, but it is designed to be quite configurable.</div><div><br></div><div>For less hand-wavy answers, I refer to the actual experts on the subject. :)</div>
<div><br></div><div>BR,</div><div>Ulf</div><br><div><div><div></div><div class="h5"><div>On 28 Apr 2011, at 10:46, Alex Arnon wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div class="h5"><div dir="ltr">
Hi All,<br><br>We've recently been discussing the security of OS and VM stacks here, and several questions came up with regards to the Erlang VM. Specifically, the values of "new" and "old" memory.<br>
As an example, take the OpenBSD Unix-like OS. These guys are fanatics for security, and take various steps to ensure that the system is as unbreakable as possible, and in the event of breakage - to make life hard (if not impossible) for the intruder.<br>
This includes:<br>- Randomization of integer handles, e.g. accepted socket ports.<br>- Randomization of memory mapping location, e.g. DLLs (SO) will be loaded in random locations in memory.<br>- Newly mapped memory pages are always zeroed before attachment to a process's virtual space.<br>
- Swap can be encrypted, or zeroed, on the fly.<br>- The memory allocator also zeroes out freed space.<br><br>In the context of the Erlang BEAM VM, we're interested in the contents of memory. What happens, for instance, when:<br>
- A process is garbage collected.<br>- A process is terminated.<br>Are the memory locations that have been "cleaned", zeroed out? Is it is, is it possible to control it?<br><br><br>Regards,<br>Alex.<br><br></div>
</div></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><font color="#888888"><br><div>
<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com" target="_blank">http://erlang-solutions.com</a></div><div><br></div><br>
</div>
<br></font></div></blockquote></div><br></div>