Détournement d’appels système

J’écris un module de kernel et j’ai besoin de détourner / envelopper certains appels système. Je force brute l’adresse sys_call_table et j’utilise cr0 pour désactiver / activer la protection de page. Jusqu’ici tout va bien (je publierai l’intégralité du code une fois que ce sera fait afin de pouvoir mettre à jour cette question si quelqu’un le souhaite)

Quoi qu’il en soit, j’ai remarqué que si je __NR_sys_read un kernel oups lorsque je déchargeais le module du kernel et que toutes les konsoles (KDE) plantaient. Notez que cela ne se produit pas avec __NR_sys_open ou __NR_sys_write .

Je me demande pourquoi cela se produit. Des idées?

PS: S’il vous plaît, n’allez pas dans le sens de KProbes, je le sais déjà et il m’est impossible de l’utiliser car le produit final doit être utilisable sans avoir à recomstackr le kernel entier.

EDIT : (append des informations)

Je restaure la fonction d’origine avant le déchargement. De plus, j’ai créé deux cas de test, l’un avec _write seulement et l’autre avec _read . Celui avec _write décharge bien, mais celui avec _read décharge et bloque le kernel).

EDIT : (code source)

Je suis actuellement à la maison et je ne peux donc pas publier le code source pour l’instant, mais si quelqu’un le souhaite, je peux poster un exemple de code dès que je serai au travail. (~ 5 heures)

    Cela peut être dû au fait qu’un thread du kernel est en read , si l’appel du read-hook ne verrouille pas le module, il ne peut pas être déchargé en toute sécurité.

    Cela expliquerait le blocage des “konsoles” (?), Car elles effectuent probablement actuellement l’appel système en read , en attente de données. Quand ils reviennent de l’appel système réel, ils vont sauter à l’endroit où votre fonction était, causant le problème.

    Le déchargement sera compliqué, mais vous devez d’abord retirer le hook, puis attendre que tous les appelants quittent la fonction hook, puis déchargez le module.

    Je joue avec linux syscall hooking récemment, mais je ne suis en aucun cas un gourou du kernel, alors je m’excuse si cela n’est pas à la base.

    PS: Cette technique pourrait s’avérer plus fiable que forcer brusquement la table sys_call_table. Les techniques de force brute que j’ai vues tendent à paniquer le kernel si sys_close est déjà accroché.