Condición de carrera en glibc/NPTL/Linux mutexes robustos?

Question

En un comentario sobre la cuestión Automatically release mutex on crashes in Unix en 2010, Jilles afirmó: mutex robustos

de glibc son tan rápido porque glibc toma atajos peligrosos. No hay garantía de que el mutex todavía exista cuando el kernel lo marque como "causará EOWNERDEAD". Si el mutex fue destruido y la memoria reemplazada por un archivo mapeado de memoria que contiene la última identificación del hilo propietario en el lugar correcto y el último hilo propietario termina justo después de escribir la palabra de bloqueo (pero antes de eliminar completamente el mutex de su lista de mutexes propios), el archivo está dañado. Los mutexes robustos de Solaris y Will-be-FreeBSD9 son más lentos porque no quieren tomar este riesgo.

No puedo entender el reclamo, ya que destruir un mutex no es legal a menos que esté desbloqueado (y por lo tanto no en la lista robusta de ningún hilo). Tampoco puedo encontrar ninguna referencia buscando tal error/problema. ¿El reclamo era simplemente erróneo?

La razón por la que pregunto y estoy interesado es porque esto es relevante para la corrección de mi propia implementación basada en la misma primitiva robusta-mutex de Linux.

Answer 1

La descripción de la raza por FreeBSD pthread desarrollador David Xu: http://lists.freebsd.org/pipermail/svn-src-user/2010-November/003668.html

No creo que el ciclo munmap/mmap es estrictamente necesario para la carrera. La pieza de memoria compartida también puede usarse de forma diferente. Esto es poco común pero válido.

Como también se menciona en ese mensaje, más "diversión" ocurre si los subprocesos con privilegios diferentes acceden a un mutex robusto común. Debido a que el nodo para la lista de mutexes robustos propios está en el mutex mismo, un hilo con privilegios bajos puede dañar la lista de un hilo de alto privilegio.Esto podría aprovecharse fácilmente para hacer que el alto subproceso de privilegios se bloquee y, en casos excepcionales, esto podría permitir la corrupción de la memoria del subproceso de privilegios. Aparentemente, los muteos robustos de Linux solo están diseñados para ser utilizados por hilos con los mismos privilegios. Esto podría haberse evitado fácilmente haciendo que la lista robusta sea una matriz completamente en la memoria del subproceso en lugar de una lista vinculada.

Answer 2

Creo que encontré la carrera, y de hecho es muy fea. Funciona de la siguiente manera:

El subproceso A ha mantenido el mutex robusto y lo desbloquea. El procedimiento básico es:

1. Colóquelo en la ranura "pendiente" del encabezado de la lista robusta de la secuencia.
2. Elimínelo de la lista vinculada de muteos robustos mantenidos por el hilo actual.
3. Desbloquee el mutex.
4. Borre la ranura "pendiente" del encabezado de la lista robusta de la secuencia.

El problema es que entre los pasos 3 y 4, otro hilo en el mismo proceso podría obtener el mutex, luego desbloquearlo, y (correctamente) creyendo ser el usuario final del mutex, destruir y liberar/munmap it. Después de eso, si un hilo en el proceso crea una asignación compartida de un archivo, dispositivo o memoria compartida, se le asigna la misma dirección, y el valor en esa ubicación coincide con el pid del hilo que todavía está entre los pasos 3 y 4 de desbloqueo, usted tiene una situación en la que, si el proceso se cancela, el kernel corromperá el archivo asignado estableciendo el bit alto de un entero de 32 bits que cree que es el ID del propietario del mutex.

La solución es llevar a cabo un bloqueo global sobre mmap/munmap entre los pasos 2 y 4 anteriores, exactamente igual que en mi solución al problema de barrera descrito en mi respuesta a esta pregunta:

Can a correct fail-safe process-shared barrier be implemented on Linux?