Non. L'interface unifiée en question, elle existe déjà et s'appelle PKCS#11.
La, l'intérêt est double :
- tout d'abord, protéger le noyau contre un environnement auquel celui-ci accorde moins de confiance : l'userspace. Ca ne sert pas à grand chose de blinder le kernel de vérification crypto si c'est pour les déléguer à l'userspace. C'est ce qu'indique patrick_g au dessous.
- ça permet aussi de fournir des services crypto à l'utilisateur (c'est ce que tu écris, il me semble). A mon avis, l'interêt dans ce scenario est surtout que ces fonctions vont avoir un niveau de confiance présumé identique à celui du kernel, qui est supérieur à celui d'une bibliothèque user space. Par contre, niveau context switching, ça reste la fête, puisque c'est toujours un processus utilisateur qui s'adresse au noyau.
[^] # Re: RSA dans le noyau
Posté par oinkoink_daotter . En réponse à la dépêche Sortie du noyau Linux 3.3. Évalué à 5.
Non. L'interface unifiée en question, elle existe déjà et s'appelle PKCS#11.
La, l'intérêt est double :
- tout d'abord, protéger le noyau contre un environnement auquel celui-ci accorde moins de confiance : l'userspace. Ca ne sert pas à grand chose de blinder le kernel de vérification crypto si c'est pour les déléguer à l'userspace. C'est ce qu'indique patrick_g au dessous.
- ça permet aussi de fournir des services crypto à l'utilisateur (c'est ce que tu écris, il me semble). A mon avis, l'interêt dans ce scenario est surtout que ces fonctions vont avoir un niveau de confiance présumé identique à celui du kernel, qui est supérieur à celui d'une bibliothèque user space. Par contre, niveau context switching, ça reste la fête, puisque c'est toujours un processus utilisateur qui s'adresse au noyau.