[erlang-questions] Erlang VM: how clean is our memory?

[Alex Arnon]

What interests me, beyond what "the allocator" does, is what happens when a
process's heap is garbage collected.
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).



On Thu, Apr 28, 2011 at 12:07 PM, Ulf Wiger
<ulf.wiger@REDACTED>wrote:

>
> I think a good starting point is to meditate over this page:
> http://www.erlang.org/doc/man/erts_alloc.html
>
> 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.
>
> The whole memory management subsystem in BEAM has become a *lot* more
> sophisticated since then, but it is designed to be quite configurable.
>
> For less hand-wavy answers, I refer to the actual experts on the subject.
> :)
>
> BR,
> Ulf
>
> On 28 Apr 2011, at 10:46, Alex Arnon wrote:
>
> Hi All,
>
> 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.
> 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.
> This includes:
> - Randomization of integer handles, e.g. accepted socket ports.
> - Randomization of memory mapping location, e.g. DLLs (SO) will be loaded
> in random locations in memory.
> - Newly mapped memory pages are always zeroed before attachment to a
> process's virtual space.
> - Swap can be encrypted, or zeroed, on the fly.
> - The memory allocator also zeroes out freed space.
>
> In the context of the Erlang BEAM VM, we're interested in the contents of
> memory. What happens, for instance, when:
> - A process is garbage collected.
> - A process is terminated.
> Are the memory locations that have been "cleaned", zeroed out? Is it is, is
> it possible to control it?
>
>
> Regards,
> Alex.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110428/6babbcfc/attachment.htm>