Après NX les processeurs intel se mettent à supporter le SMEP [1].
Qu'est ce que c'est ?
C'est un NX un peu particulier : la mémoire taggé (via la mmu) avec ce flag ne pourra pas être exécuté en mode superviseur (ie en mode kernel).
Ca devrait empêcher certains exploits.
Ce qui est marrant c'est que l'on se rapproche de plus en plus de ce qu'offrait la segmentation sur les premiers processeur intel (une zone mémoire pour les data/stack/code en user et superviseur).
A quand le flag mmu pour la stack ?
[1].
https://lkml.org/lkml/2011/5/16/500
PS : ca n'aurait pas été plus propre de faire un "SMP" (Supervisor Mode Protection), ie une protection a la fois sur l'exécution et les data ?
# Accés kernel
Posté par superna (site web personnel) . Évalué à 4.
Pour la dernière question, non, le kernel a besoin d'avoir accès aux pages des applications !
Les appels read/write/... passent l'adresse dans le contexte de l'application et le kernel doit le remapper et y accéder.
L'avantage du SMEP est que ces mappages applicatifs ne seront pas exécutables si le kernel est corrompu (exemple: code malicieux qui suit un buffer qui a la mauvaise taille, driver buggé qui ne vérifie pas la taille du buffer et écrase ses propres pointeurs par des adresses contenue en user space, le SMEP stoppera l'exécution !).
[^] # Re: Accés kernel
Posté par M . Évalué à 2.
oui mais dans le cas de linux, l'accès ce fait par un autre mapping (direct mapping).
De plus on parle de page exécutable, je vois pas ce que le kernel ferais dedans.
[^] # Re: Accés kernel
Posté par superna (site web personnel) . Évalué à 1.
Les swapper ?
# Segmentation: les SE en faute ?
Posté par Kerro . Évalué à 4.
Ce mode existe toujours (à ma connaissance), mais ce sont les SE, Linux par exemple, qui ne l'utilisent pas. La cause à "pas pratique" malgré le fait que les pages étaient censées palier le problème.
[^] # Re: Segmentation: les SE en faute ?
Posté par barmic . Évalué à 2.
Je vais peut être dire une grosse ânerie mais la segmentation dont on parle elle est a taille fixe si je me souviens bien. Au démarrage le noyau crée le ou les segments et ce n'est plus modifiable, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Segmentation: les SE en faute ?
Posté par serianox . Évalué à 1.
Linux n'utilise pas (plus) la segmentation ; c'est un concept trop peu répandu, du coup le MM n'utilise que la pagination qui est disponible dans quasiment toutes les MMU, ce qui rend le code de gestion de la mémoire portable.
Linux met juste en place un flat memory model au démarrage sur IA32, mais il me semble que fs et gs sont quand même utilisés en particulier pour le stack protector. Au passage, la segmentation disparaît dans EMT64. En effet, il est nécessaire de passer en flat memory model avant de pouvoir basculer en 64 bit.
[^] # Re: Segmentation: les SE en faute ?
Posté par M . Évalué à 3.
fs et gs sont utilisé comme des registres (read_mostly) supplémentaire qui pointe sur des données. Ils servent pour implémenter les TLS (user/kernel) et le stack protector.
C'est dommage qu'ils n'aient pas fournie une meilleur alternative...
[^] # Re: Segmentation: les SE en faute ?
Posté par Kerro . Évalué à 2.
Les segments sont modifiables sans problème. Ca reste moins souple que d'utiliser les pages, mais c'est plus performant côté sécurité. Enfin historiquement, puisque maintenant le mécanisme des pages va avoir les mêmes avantages.
Je me demande quel SE utilise les segments. Je crois qu'OS/2 Warp le faisait.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Encore un journal imbitable
Posté par Astaoth . Évalué à 3.
J'avoue qu'une petite explication de ce qu'est un NX (sur le moment, j'ai pensé à Star Treck), et ce qu'est la mémoire tagguée, ca n'aurait pas été de trop pour rendre ce journal accessible aux néophytes.
Emacs le fait depuis 30 ans.
[^] # Re: Encore un journal imbitable
Posté par phyce . Évalué à 4.
Faut quand même admettre que c'est plutot un journal d'hommes...
( http://www.youtube.com/watch?v=XqtH3n3QgYU )
[^] # Re: Encore un journal imbitable
Posté par khivapia . Évalué à 6.
Traduction: chaque page mémoire est marquée avec différents tags dont le plus récemment introduit (sur architecture x86) est le bit NX.
Les tags sont en général R, W, X : la page est accessible en lecture, en écriture, ou en exécution.
AMD a introduit le bit NX sur architecture x86 afin que les noyaux puissent rendre diverses zones mémoire non exécutable pour éviter certaines attaques (nom marketing : protection matérielle contre les virus). L'idée est qu'une page accessible en écriture ne soit pas exécutable, afin qu'un attaquant ne puisse pas insérer directement son code : toute donnée écrite par un programme n'est que des données, pas du code du programme lui-même.
Cette saine pratique empêche également celle, malsaine en terme de sécurité, du code auto-modifiant (malsaine également pour les performances, les processeurs n'ayant pas dans l'idée que le code puisse être modifié, le cache instruction écronomise de la logique). La rumeur voudrait que ce soit cette raison qui ait rendu l'implémentation du bit NX tardive sous windows (à cause de Microsoft Office, pour les macros).
[^] # Re: Encore un journal imbitable
Posté par Guillaume Knispel . Évalué à 3.
wtf???
[^] # Re: Encore un journal imbitable
Posté par ymorin . Évalué à 2.
Je ne sais pas si cette assertion est vraie ou non. Cependant, il serait envisageable qu'un interpréteur de macros génère des datas qui soient en fait des opcodes x86, qu'il exécute ensuite. Ca nécessite des pages W, pour y mettre les opcodes, et X pour exécuter ces opcodes. Un espèce de JIT, en gros.
Attention, je n'ai pas dit que c'est ce que l'interpréteur de macros MSOffice faisait.
Hop,
Moi.
[^] # Re: Encore un journal imbitable
Posté par pasBill pasGates . Évalué à 4.
Il raconte n'importe quoi. l'OS fournit des APIs pour rendre des pages executables, ce qui permet aux VMs JIT de fonctionner sans probleme, creer ces APIs n'a certainement pas pris plus de quelque heures et les revoir/tester plus de quelques jours...
Le support a ete ajoute dans XP SP2, sorti en Aout 2004, et elles sont apparues dans le kernel 2.6.8, sorti en Aout 2004... Il y avait bien les patchs Exec-Shield & PaX, mais PaX n'a jamais ete accepte car bcp trop invasif, et Exec-shield est sorti en 2003, mais n'a ete integre qu'a partir de RHEL 3 update 3, aux alentours d'Aout 2004...
[^] # Re: Encore un journal imbitable
Posté par benja . Évalué à 7.
Il n'y a pas que linux vs MS dans la vie :p
«OpenBSD 3.3 shipped May 1, 2003, and was the first operating system to include W^X.»
«W^X makes use of the NX bit on Alpha, AMD64, HPPA, and SPARC processors.»
Avec en prime une émulation utilisant aussi les registres de segmentation pour les IA-32 n'ayant pas de bit NX; ce que Windows ne fait pas (ce n'est pas encore clair pour moi de savoir si linux sans PaX le fait). [source wikipedia]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Encore un journal imbitable
Posté par Ph Husson (site web personnel) . Évalué à 3.
Euh .... On a pas NX = !X ?
Si c'est le cas.... pourquoi rajouter un bit ?
[^] # Re: Encore un journal imbitable
Posté par inico (site web personnel) . Évalué à 1.
NX marque explicitement une page comme non exécutable le long de sa vie, empêchant les petit malin de la rendre exécutable plus tard ...
[^] # Re: Encore un journal imbitable
Posté par khivapia . Évalué à 2.
Par défaut sous x86, tout était exécutable.
# Quelques questions
Posté par Michaël (site web personnel) . Évalué à 3.
Apparemment tu en connais bien plus que moi sur la machine, aussi j'ai une question: des vagues souvenirs que je garde de mon expérience de programmeur asssembleur, il me semble qu'en mode protégé les tables LDT et GDT décrivent des pages (assoicées à une tâche pour la LDT) qui sont effectivement marquées avec des attributs de type R/W, un niveau de sécurité et si elles offrent une «trappe» permettant de gagner un niveau de sécurité.
Comme tu le vois, je ne comprends pas ce qu'apporte le SMEP: je coryais que le code superviseur devait se marquer lui-même en déclarant qu'une intrerruption ou une adresse de procédure devait s'effectuer en mode superviseur. Ce serait super sympa si tu pouvais expliquer un peu la différence entre le SMEP et ce qui est déjà disponible sur les i386 via les LDT/GDT.
[^] # Re: Quelques questions
Posté par Guillaume Knispel . Évalué à 4.
LDT et GDT décrivent des segments. La majorité de la protection sur x86 se situait dans les segments, mes ces derniers n'étaient pas utilisés. Il a donc fallu introduire plus de protection dans les pages (surtout maintenant que l'amd64 supprime encore plus les segments)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.