<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 26, 2018 at 7:40 PM, james hughes <span dir="ltr"><<a href="mailto:hughejp@me.com" target="_blank">hughejp@me.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><div><blockquote type="cite"><div>On Jun 24, 2018, at 4:11 PM, Yann Ylavic <<a href="mailto:ylavic.dev@gmail.com" target="_blank">ylavic.dev@gmail.com</a>> wrote:</div><br class="m_-5535776769161576099Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">I wonder how I'd best handle fork()ed processes,</span></div></blockquote></div></span></div></blockquote><div>...... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""></span><div>Simple. Use an RNG that does not keep state in the application. </div><div><br></div><div><ul class="m_-5535776769161576099MailOutline"><li>Use a hardware RNG</li><li>Use a kernel level RNG that does not provide bits until it has sufficient entropy.</li></ul></div><div><br></div><div>Confused. <br></div></div></blockquote><div> </div><div>Slightly confused as well.<br>Fork by design keeps a lot of state and the state of the PRNG is only one interesting bit of state.<br>Everything other than the return value is the same, everything. <br>Both the parent and the child can call for a system *rand value for a new seed.<br>One or both.... both because some history might leak from parent to child.<br>Copy on write can help. malloc() and friends might hide a lot of malloc() fragmented cruft that is passed from parent to child to child to child... </div><div>i.e. objects not yet written to are in the map for inspection. Garbage collection?<br><br>Benchmark fork() and tidy(all) vs fork(); exec() and also vfork(); exec()<br><br>The very first parent can fork(); exec(generator) where the generator can listen for a localhost connection and <br>return random bits on demand. A generator can be quick and if the system *rand() services are suspect<br>it can ignore them or if they are golden use the heck out of them. It can be poked with signals to fetch hardware </div><div>random bits from some other good local or far service. If a PRNG is sufficient this might isolate this design problem <br>into one object.<br><br>It might be possible to build a generator using tricks that node uses to be such a quick web server.</div><div><br></div><div>Fork is safe in some constrained well managed cases. <br>What if the parent never sees random bits or other secrets and simply forks() to get work done knowing that it is safe to <br>do so because there are no secrets in the parent to worry about. Now the child can make a call to a system *rand device<br>check the return value so it knows it got enough and then go to work. <br><br>What happens if there are multiple copies or the parent/ child exits with an error. What process can wait()</div><div>to catch child exit/death signals (no zombies or orphans please)? Is an orderly system shut down well managed? </div><div>How does this design play in a migrating VM or is this a documented out of scope issue. i.e. is it cloud safe. <br><br>How fast must it be?</div><div><br></div><div><br></div><div><br><br><br> <br><br><br><br><br><br></div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"> T o m M i t c h e l l</div></div>
</div></div>