Conventions de codage sécurisées dans le noyau Linux

Question

Lors de l'examen du code du noyau, j'ai rencontré la situation suivante.

Supposons que nous ayons deux composants du noyauA et B (par exemple, les modules du noyau), avec un invoquant un EXPORT_SYMBOL « ed some_func() de B. Supposons que some_func() possède des arguments d'entrée, qui doivent être affectés uniquement aux valeurs "légitime" ou "valide". Par exemple, supposons que nous avons

some_func(void * p); 

où void * p devrait être non NULL, montrant peut-être aussi à une partie de la mémoire allouée correctement.

Ma question est: qui est responsable que les arguments de some_func() sont en effet légitimes? Est-ce l'appelant A ou l'appelé B? Je n'ai pas été en mesure de trouver une source faisant autorité décrivant quelle convention devrait être suivie dans le noyau. Lorsque l'on considère l'exemple d'argument d'entrée de pointeur, du point de vue de la sécurité, il est clair que nous pourrions rencontrer un problème de déréférencement NULL -pointer, qui devrait être évité. Alors, de se spécialiser ma question, est Une responsable de la sécurité des arguments qu'il passe à B, ou si B ont placé à l'validations d'entrée à chaque symbole qu'elle exporte?

Veuillez noter que cette question concerne l'appel des conventions au sein du noyau, et non liée aux conventions d'appel de l'espace utilisateur.

Answer 1

Tout le code du noyau fonctionne au même niveau de privilège. C'est donc une erreur de programmation de passer un argument invalide du tri. Pour les coups de pied, disons que B tente de valider d'une façon ou d'une autre. Clairement, la vérification NULL est triviale. Mais comment vérifiez-vous les points de pointeur à quelque chose que vous pouvez accéder? Voici un kicker bonus: que se passe-t-il si B a validé, a conclu son amende, puis le code du module A en cours d'exécution sur un autre processeur a libéré la zone cible. Si B accède maintenant, tout le travail a été rendu inutile.

Mais pourquoi jouer comme ça si vous avez les mêmes permissions que B. Si vous le souhaitez, vous pouvez directement écraser son code. Comme vous pouvez le voir, la question est définitivement discutable.

D'un autre côté, comparons cela avec l'espace utilisateur. noyau < -> l'interface utilisateur est une frontière de sécurité, les données/pointeurs transmis sont intrinsèquement non fiables et accessibles uniquement via des primitives dédiées garantissant la sécurité. Notez la différence fondamentale dans la capacité à fournir une garantie: vous accédez, cela peut déclencher une erreur de page et si cela s'est produit et il n'y a rien à mapper, vous savez que l'espace utilisateur tourne autour et vous pouvez retourner une erreur. Si la même chose arrive pour le code du noyau, vous avez un bug.