Scott Cheloha <[email protected]> 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??
