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