Que se passe-t-il lorsque votre mémoire mlock (2) est déjà permutée?

Question simple, mais je n'ai pas trouvé de réponse.

Si une page en mémoire a déjà été échangée sur le disque par le noyau et que son processus propriétaire appelle mlock (2) ou VirtualLock sur cette page en mémoire, que se passe-t-il?

Est-il retourné immédiatement à la mémoire physique? Est-il effacé du disque? Si l'on retarde l'écriture d'informations sensibles dans une page après l'appel de mlock (2), cela garantirait-il que cela n'est pas écrit sur le disque?

En guise de question mineure de suivi, que feriez-vous pour atténuer une telle éventualité?

Sur une version actuelle en amont du noyau Linux, les pages seront renvoyées par erreur, mais il semble en laisser des copies dans l’échange.

Je pense que la plupart des systèmes BSD et autres systèmes UNIX se comportent de la même manière, mais je ne suis pas sûr de Windows.

Retarder l'écriture de quelque chose jusqu'à ce que mlock () soit appelé empêche les données d'être échangées, mais ne peut garantir que les données ne seront pas écrites sur le disque, à moins que l'hibernation avec ACPI S4 et le système d'exploitation ne soit pas possible et que vous ne soyez pas dans un ordinateur virtuel. (Si vous êtes dans une machine virtuelle, vous pouvez vous trouver sous un hyperviseur de type 1 et donc soumis aux contraintes de mémoire virtuelle du système hôte, que vous ne pouvez pas contrôler).

Par conséquent, une atténuation appropriée implique:

• Traitement au niveau de l'application pour empêcher les données sensibles de résider dans la RAM plus longtemps que nécessaire, même si la région est verrouillée.
• Traitement au niveau système pour désactiver ACPI S4 (généralement nécessaire uniquement sur les systèmes OEM), empêcher l'hibernation médiée par le système d'exploitation et assurer la confiance dans le système hôte si elle est exécutée sur une machine virtuelle.