<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 12:09 PM, Nico Williams <span dir="ltr"><<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right.  One should not, however, call syscall(2) to avoid libc stubs.<br>
It's very dangerous for precisely this sort of reason.<br></blockquote><div><br></div><div>Dangerous but attractive can be a bad combination; there are runtimes and VMs that use the syscalls directly because they want to emulate their own lightweight processes. For their environment, it makes sense - to them. Then sometimes these same environments will also embed a native crypto library, for performance reasons, and we have an unsafe combination of events if the native library is relying on pthread_atfork. Everyone is doing something that mostly makes sense "for them", but users can still end up with an insecure combination. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> What should work as an MADV_WIPEONFORK replacement is a MAP_SHARED<br>
</span>> mapping and two counters, [...]<br>
<br>
Clever.  You can also just check that (my_saved_pid == getpid()), which<br>
if you have a fast getpid() via a vdso, is cheap.<br></blockquote><div><br></div><div>This isn't safe because PIDs can be re-used.</div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Colm</div>
</div></div>