[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reauthentication implementation flaw due to EINTR

From: Samuel Thibault
Subject: Re: Reauthentication implementation flaw due to EINTR
Date: Mon, 28 Dec 2009 02:29:11 +0100
User-agent: Mutt/1.5.12-2006-07-14

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]