<div dir="ltr">Hi Amit,<div><br></div><div>Regarding the sensitive flag:</div><div><ul><li>I like the idea of only zeroing memory of sensitive processes, it sounds like a sensible thing.</li><li>However, beware that this flag is not used widely enough. For example, I found no usage of it in the OTP source code (except for some test cases verifying it actually works), although applications like ssl could probably make good use of it. Similarly, on GitHub there are only <a href="https://github.com/search?l=Erlang&q=process_flag+sensitive&type=Code">313 hits</a> if you search for the flag (with a lot of false positives). So you'd definitely have to audit your libraries, such as your webserver, on whether they mark all processes with sensitive data as sensitive.</li><li>For the above reason, I wouldn't worry that much about performance impact on existing applications. But just to be on the safe side, you could add a command line switch for turning the new feature on, leaving it off by default.</li><li>What you should worry about are things like shared, reference-counted binaries. They may be shared between sensitive and non-sensitive processes, so do they have to be zeroed or not? What about the memory allocated by NIF-s in sensitive processes? Like the openssl data structures where crypto will copy the keys? I have a feeling that blindly zeroing every freed up memory is inefficient, but doable, while extending the sensitive concept to cover every aspect of the BEAM VM may not be feasible at all.</li></ul><div>Regarding more fine grained control via marking terms as sensitive instead of entire processes: I don't think this would be a good idea in practice.</div></div><div><ul><li>The BEAM VM reserves a few low bits in each  word of memory for <a href="https://blog.stenmans.org/theBeamBook/#_the_tagging_scheme">type tags</a>. To mark any term as sensitive, you'd need an unused tag bit, which you don't have. There is one unused tag bit combination for boxed types left, so you could in theory introduce a new, "sensitive data" term type, but that's not feasible to implement. For boxed types on x64, you could also use the top 16 bits of the pointer for meta-data, as currently the physical addresses are only 48 bit wide on this platform. But this also seems unreasonably complicated and isn't even portable to other architectures.</li><li>Even if you could tag each sensitive term, this wouldn't make the GC faster. The GC only visits (and copies) live terms. I'm pretty sure that reading in every dead term, checking whether they're sensitive and then selectively zeroing parts of the memory would be much-much slower in practice than just blindly zeroing over the entire memory area. We are talking about out of order CPU-s with precious, limited cache space here.</li><li>What may work instead is to maintain a list of sensitive terms on the heap for each process. This is probably not impossible to do (e.g. processes already maintain a list of shared, reference-counted binaries they use), but it seems impractically complicated.</li></ul></div><div><br></div><div>Daniel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 27 Oct 2019 at 17:34, Amit K <<a href="mailto:klg.amit@gmail.com">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Eric,<div>I like your suggestion, but would it be a reasonable performance overhead, especially for those who are already using the sensitive flag for certain processes? If the answer is likely yes I may well try to implement this and possibly create a PR for that :) </div></div><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 9:21 AM Eric Pailleau <<a href="mailto:eric.pailleau@wanadoo.fr" target="_blank">eric.pailleau@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr" style="margin-top:0px;margin-bottom:0px">Hi, </p>
<p dir="ltr" style="margin-top:0px;margin-bottom:0px">Note that there is a sensitive flag for processes. </p>
<p dir="ltr" style="margin-top:0px;margin-bottom:0px">Would be neat that variables used by sensitive processes get their memory zeroed. </p>
<br>
<p dir="ltr" style="margin-top:0px;margin-bottom:0px">Envoyé depuis mon mobile </p><br><br>---- Amit K a écrit ----<br><br><div dir="ltr">Hi Daniel,<div><br></div><div>Good to know about that workaround, thank you. However as you already pointed out, I really do want to be able to handle such "sensitive" variables in Erlang code and use the standard "crypto" library of the OTP. </div><div><br></div><div>With regards to GC - that's a great direction I think, and perhaps a more finer grained approach would be to add a new "sensitive" flag for typed variables that the GC can recognize. Then only those variables get zeroized when the GC runs. </div><div>Would probably be better for performance than always zeroizing everything that we free...</div><div><br></div><div>BTW - so far I didn't find any FP language that can do something like that, and please correct me if I'm wrong. It would be cool if Erlang would be the first to the gold here (again!) :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 1:42 AM Dániel Szoboszlay <<a href="mailto:dszoboszlay@gmail.com" target="_blank">dszoboszlay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Amit,<div><br></div><div>A NIF could use a resource object to implement a zeroable memory location. The Erlang program will only see a handle to the resource, which is immutable. But the contents of the object can be changed by the NIF (it's better explained in the <a href="http://erlang.org/doc/man/erl_nif.html" target="_blank">docs</a>). So you could create an API that looks like this for the Erlang program:</div><div><br></div><div><font face="monospace">Handle = create_secret(Some, Input, Values),</font></div><div><font face="monospace">ok = use_secret(Handle),</font></div><div><font face="monospace">ok = destroy_secret(Handle), % The NIF zeroes out the memory in the resource object</font></div><div><font face="monospace">{error, destroyed} = use_secret(Handle). % The secret is no more at this point</font></div><div><br></div><div>The big problem is that your secret shall never leave the native library. E.g. you cannot hide a cryptographic key behind a zeroable resource object and then pass it to the crypto library. As soon as you convert it into an Erlang term, it is copied onto the non-zeroed stack or heap or a process. Considering this, you may just as well use a port program to hold and work with the secret outside of the Erlang VM.</div><div><br></div><div>Probably the only real solution within the VM would be to patch the GC to zero any reclaimed memory. Or maybe not even the GC, but the memory allocators, in case a secret is copied to some non-GC-d memory area, such as an ETS table.</div><div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 26 Oct 2019 at 22:39, Amit K <<a href="mailto:klg.amit@gmail.com" target="_blank">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Concerning the security practice of Zeroizing sensitive data from memory after you're finished with it, such as Cryptographic keys, passwords, etc, I wanted to ask if any of you ever had to implement such a thing in Erlang, and if so, how? :) </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Also note that often this is a requirement that you must fulfill if you want your product to pass a security standard evaluation such as the "Common Criteria" one (As an example requirement see 

FCS_CKM_EXT.4 here: <a href="https://www.commoncriteriaportal.org/files/ppfiles/pp_nd_v1.0.pdf" style="font-family:Arial,Helvetica,sans-serif;font-size:small" target="_blank">https://www.commoncriteriaportal.org/files/ppfiles/pp_nd_v1.0.pdf</a>).</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">The problem of course is that in Erlang (and I suppose - FP in general) once a variable gets assigned, you are not allowed to change its value, and in particular of course overwrite it with zero bytes. </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">One option I thought about is doing it with a NIF, but from my understanding a NIF isn't supposed to change its input values, it should treat them as constants, which understandable as well (basic FP language property). </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Any feedback can be helpful :)</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Regards,</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Amit</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><div><br></div><div><br></div></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>