Scott Cheloha <scottchel...@gmail.com> wrote: > > Am I wrong that kbind is never called twice in the same address space? > > Isn't this exactly what happened the last time we tried this?
Tried what? kbind has never been NOLOCK. > > Can someone describe a synthetic sequence where racing sys_kbind calls > > perform the wrong action? > > This is highly synthetic, but: > > If Thread1 Stop right there. Is this in a static binary or a dynamic binary? In a dynamic binary, ld.so has used kbind(), and kbind() cannot be used again. In a static binary, early_static_init() calls kbind() and locks you out. When were these threads created? > sets ps_kbind_addr before Thread2 but Thread2 compares > ps_kbind_cookie with SCARG(uap, proc_cookie) before Thread1 can change > ps_kbind_addr from 0 to its own SCARG(uap, proc_cookie) it is possible > that Thread2 will pass the security check and proceed, even though it > should have caused a SIGILL. You cannot call kbind() synthetically, from the manual page: kbind is currently intended for use by ld.so(1) only. That is why there is no libc stub for it. That's why dlg's demo program replaces the libc one with a raw assembly version, so that it can call it. > Thread2 knows ps_kbind_cookie is initialy zero, so there is a > theoretical race. Again, how did you end up with threads, and how did you call kbind without using assembly language, and what program would ever do this? > If you wanted to make this statistically impossible you could > initialize ps_kbind_cookie to a random value during fork(2) so that > Thread2 has a 1 in 2^64 chance of guessing the the initial > ps_kbind_cookie value and bypassing the security check as > described above. Where did these threads come from before ld.so completed linkage resolution??