Re: Reauthentication implementation flaw due to EINTR

[Samuel Thibault]

Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit :
> AFAICT, after auth_server_authenticate_reply returns _hurdsig_abort_rpcs
> can not hijack it, so your solution should work.

I've checked more in the kernel internals, maybe there is a race
window, even if very unlikely.

ext2fs is in auth_server_authenticate()'s receive part, let's
assume it's already queued on the receive mqueue->imq_threads from
ipc_mqueue_receive(). In that case, auth_server_authenticate_reply()
finds it and sets ith_state to MACH_MSG_SUCCESS. When ipc_mqueue_receive
wakes up, it finds that first, before checking whether ith_wait_result
is THREAD_INTERRUPTED, so we win.

However, can it be that ext2fs may have sent its message (triggering
everything in auth etc.) but not yet blocked in ipc_mqueue_receive()
when the auth_server_authenticate_reply comes? In that case, it may not
have the time to receive the message before auth_user_authenticate()
returns and the reply port gets dead, triggering an interrupt.  I can
see locks on spaces and ports, but in mach_msg_trap, it seems that at
label slow_get_rcv_port we don't have any lock left on send part.

Samuel