Il modo migliore per comunicare da KEXT a Daemon e bloccare finché non viene restituito il risultato da Daemon

Question

In KEXT, sto ascoltando la chiusura del file tramite vnode o listener di scope del file. Per alcuni (pochissimi) file, ho bisogno di inviare il percorso del file al mio demone di sistema che esegue qualche elaborazione (questo deve succedere in demone) e restituisce il risultato a KEXT. Il file close call deve essere bloccato fino a quando non ottengo risposta da demone. In base al risultato, è necessario eseguire alcune operazioni in una chiamata chiusa e restituire correttamente la chiamata in chiusura. C'è molta discussione sull'argomento relativo alla comunicazione KEXT sul forum. Ma non sono conclusivi e sembrano essere molto vecchi (anno 2002 circa). Questo requisito può essere gestito dall'API Win32 FtlSendMessage(...). Sto cercando equivalente di quella su Mac

Ecco quello che ho guardato e vuole riassumere la mia comprensione:

1. Mach messaggio: Fornisce ottimo modo di comunicazione bidirezionale con mittente e rispondere porte con meccanismo di messa in coda. Tuttavia, le API dei messaggi mach (ad esempio mach_msg, mach_port_allocate, bootstrap_look_up) non sembrano essere KPI. L'API mach mach_msg_send_from_kernel può essere utilizzata, ma da sola non aiuta nella comunicazione bidirezionale. La mia comprensione è giusta?
2. IOUserClient: questo sembra avere più a che fare con la comunicazione dallo spazio utente a KEXT e poi avere alcune chiamate da KEXT. Non ho trovato un modo per avviare la comunicazione da KEXT a daemon e quindi attendere il risultato da demone. Mi sto perdendo qualcosa?
3. Socket: Questa potrebbe essere l'ultima opzione poiché dovrei implementare l'intero canale di comunicazione bidirezionale da KEXT a Daemon.
4. ioct l/sysctl: Non ne so molto di loro. Da quello che ho letto, la sua opzione non raccomandata in particolare per la comunicazione bidirezionale
5. RPC-Mig: Ancora una volta non ne so molto di loro. Sembra complicato da quello che ho visto. Non sono sicuro se questo è il modo consigliato.
6. KUNCUserNotification: Sembra che stia appena fornendo una notifica all'utente da KEXT. Non soddisfa il mio requisito.

La piattaforma supportata è (da 10,5 in poi). Quindi, guardando il requisito, qualcuno può suggerire e fornire alcuni suggerimenti su questo argomento?

Grazie in anticipo.

Answer 1

Lo schema che ho usato per quel processo è di avere il processo dello spazio utente per iniziare una connessione socket a KEXT; il KEXT crea un nuovo thread per gestire i messaggi su quel socket e dorme il thread. Quando KEXT rileva un evento a cui deve rispondere, attiva il thread di messaggistica e utilizza il socket esistente per inviare i dati al daemon. Alla ricezione di una risposta, il controllo viene passato al thread richiedente per decidere se porre il veto sull'operazione.

Non so di ogni singolo risorsa che descriverà completamente tutto quel modello, ma i KPI rilevanti sono discussi in Mac OS X Internals (che sembra vecchio, ma i KPI non sono cambiate molto da quando è stato scritto) e OS X and iOS Kernel Programming (di cui ero un revisore tecnico).

Answer 2

Se si desidera utilizzare la presa stabilita con ctl_register() sul lato KExt, fare attenzione: la comunicazione da kext allo spazio utente (tramite ctl_enqueuedata()) funziona correttamente. Comunque la direzione opposta è buggata su 10.5.xe 10.6.x.

Dopo circa 70.000 o 80.000 send() chiamate con SOCK_DGRAM nelle PF_SYSTEM dominio completi pause pila nette con conseguenze disastrose per sistema completo (hard spegnendo è l'unica via di uscita). Questo problema è stato risolto in 10.7.0. Ho risolto il problema utilizzando setsockopt() nel nostro progetto per la direzione dallo spazio utente a kext in quanto inviamo solo dati molto piccoli (solo per consentire/non consentire alcune operazioni).

Answer 3

Per quel che vale, autofs utilizza ciò che io presumo si intende per "RPC-Mig", quindi non è troppo complicato (MIG è usato per descrivere le chiamate RPC, e il codice stub che genera maniglie chiamando l'appropriata Invio e ricezione di messaggi Mach, ci sono opzioni speciali per generare stub in modalità kernel).

Tuttavia, non è necessario eseguire alcuna ricerca, poiché automountd (il daemon in modalità utente a cui gli autofs kext invia messaggi) ha una "porta speciale host" assegnata. Fare le ricerche per trovare un servizio arbitrario sarebbe più difficile.