Pour rappel NX signifie No eXecute, cette technologie rend plus difficile l'écriture de code malicieux utilisant des exploits de types dépassement de tampon ou dépassement de pile. En effet les processeurs disposant de la technologie NX ajoutent deux drapeaux aux pages mémoires allouées, à savoir le drapeau 'execute' et le drapeau 'no execute' ; ce dernier interdit l'exécution de la zone mémoire allouée.
Aller plus loin
- L'annonce sur la LKML (3 clics)
- Le patch (6 clics)
- Les RPMS (2 clics)
- Comment patcher son noyau pour le NX (13 clics)
# Desole...
Posté par pasBill pasGates . Évalué à 10.
[^] # Re: Desole...
Posté par jujubinche007 . Évalué à 2.
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 8.
[^] # Re: Desole...
Posté par Guillaume POIRIER . Évalué à 7.
Sinon, d'après ce que je sais (lu dans Understanding the Linux Kernel: http://www.oreilly.com/catalog/linuxkernel/(...) ), presque tous les processeur n'ayant pas de casserolles à traîner pour compatibilité ascendante (donc non-X86) ont la possibilité de protéger leurs pages mémoire. Cette technologie est donc tout sauf nouvelle.
[^] # Re: Desole...
Posté par Volnai . Évalué à 1.
[^] # Re: Desole...
Posté par ckyl . Évalué à 5.
Systèmes batards (gestion niveau segmentation plus ou moins réussi) : i386, powerpc
Qui ne gère rien :arm, m68k, mips, sparc, vax
(oui sparc et ppc apparaissent plusieurs fois :-)
http://citeseer.ist.psu.edu/jacob97memory.html(...)
http://citeseer.ist.psu.edu/34758.html(...)
[^] # Re: Desole...
Posté par tao popus . Évalué à 0.
[^] # Re: Desole...
Posté par ckyl . Évalué à 2.
Trouves moi la dedans ou c'est dispo.
http://e-www.motorola.com/files/32bit/doc/ref_manual/M68040UM.pdf(...)
http://e-www.motorola.com/files/32bit/doc/ref_manual/MC68040UM.pdf(...)
[^] # Re: Desole...
Posté par ange_thom . Évalué à 2.
[^] # Re: Desole...
Posté par choocroot . Évalué à 5.
Le 68881 et 68882 ne sont pas des MMU mais des coprocesseurs arithmetiques (FPU) et les 68030, 68040, etc. ont une MMU integré.
De plus, avoir une MMU ne veut pas dire qu'elle gère les protections W^X. La pagination est une chose, et le fait de pouvoir déclarer une page comme non executable en est une autre.
[^] # Re: Desole...
Posté par vrm (site web personnel) . Évalué à 6.
[^] # Re: Desole...
Posté par Jean-Baptiste SANNIER . Évalué à 2.
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 7.
[^] # Re: Desole...
Posté par itstimetogo . Évalué à 5.
From: Arjan van de Ven
On Wed, Jun 02, 2004 at 02:13:13PM -0700, Linus Torvalds wrote:
> (...)
> Just out of interest - how many legacy apps are broken by this? I assume
> it's a non-zero number, but wouldn't mind to be happily surprised.
based on execshield in FC1.. about zero.
Le noyau avec nx est dans rawhide. La mise en production sera très rapide.
[^] # Re: Desole...
Posté par 007 . Évalué à 1.
De la mailing devel de fedora :
De: Arjan van de Ven
On Thu, 2004-06-03 at 17:06, Neal D. Becker wrote:
> >From the features I'd like to see department:
>
> http://kerneltrap.org/node/view/3240(...)
the plan is to include this in the upcomming FC2 kernel update....
(think "next few weeks")
Quelques semaines pour un update officiel FC2 avec cette "feature".
[^] # Re: Desole...
Posté par Pierre Tramo (site web personnel) . Évalué à -2.
[^] # Re: Desole...
Posté par Pierre Tramo (site web personnel) . Évalué à -6.
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 5.
[^] # Re: Desole...
Posté par fredd . Évalué à 0.
Ah ? C'est comme toutes les autres versions de Windows alors ? ;)
[^] # Re: Desole...
Posté par B. franck . Évalué à 0.
comme tout bon correctif de chez kro, il corrige un problème et pète tout ce qui est autour.
Mais ils ont l'excuse toute trouvé: ils sortent tout en béta test
"Bah! on vous avait dit que c'était du béta!"
(un peu comme winXP lorsqu'il aura quitté son stade actuel: alpha)
[^] # Re: Desole...
Posté par udok . Évalué à 1.
alors que sous windows, il faut installer une sp2 en version beta, la partie pour le nx étant sans doute tout aussi stable que celle de linux, mais si la sp2 est encore en béta, c'est qu'il reste des problèmes avec, pour un usage courant
enfin c'est vraiment un guèguerre de polichinel ...
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 1.
C'est bien pour ca que je dis que c'est 'bleeding edge' , c'est pas dans le kernel par defaut, car c'est considere trop 'neuf' et pas assez teste.
[^] # Re: Desole...
Posté par Jerome Herman . Évalué à 10.
Sauf qsue la c'est de l'emulation au niveau OS vu que les CPUs x86 sont incapables de faire du NX en natif.
A noter qu'avant XP SP2 windows 2003 serveur possedait déjà cette option mais qu'il fallait l'activer a la compilation. 2003 est d'ailleurs compilé avec le full NX a savoir interdiction d'execution depuis la pile et protection de segments mémoire en non excutable (NX = Not eXecutable). Il est egalement possible de compiler en NX application par application depuis VS .net (options a passer aux compilos) le programme rejettera alors toute demande de jumper un segment de la pile.
Les *BSD font cela en natif depuis des années (ie si le processeur le supporte) vu que la fonction était implementé dans 4.4 BSD. Un support pour une emulation sur processeur x86 a été ajouté dans OpenBSD 3.4 l'année dernière.
Encore avant cela Windows NT4 alpha faisait déja du NX full, mais pour des raisons de compatibilité il n'était pas forcé par l'OS et était très peu utilisé.
Ceci étant le premier a avoir implementé une gestion NX natif forcée au niveau OS (ie toutes les applis protégées par défaut) doit être VMS ou l'OS alpha de digital (TRU64 je crois) aux alentours de 1980...
Kha
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 10.
Sinon, il me semble que le patch de Molnar ne contient pas d'emulation sur les cpu Intel, il ne fait qu'etendre la pagetable pour supporter le bit NX des CPU qui ont la feature selon l'e-mail sur la ML.
Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.
[^] # Re: Desole...
Posté par Jerome Herman . Évalué à 6.
Ha bon ? Mince je m'etais laissé emberlificoter par l'article dans MISC alors. Il me semblait que WS2003 refusait de jumper la pile. Il va falloir que je me plonge sérieusement la dedans pour voir.
Même chose pour VS.net...
sans support CPU c'est impossible d'avoir un truc vraiment efficace et qui ne bouffe pas les perfs.
La on est d'accord. A mois de virtualiser tous les accès mémoire, sous x86 point de salut.
Sinon, il me semble que le patch de Molnar ne contient pas d'emulation sur les cpu Intel, il ne fait qu'etendre la pagetable pour supporter le bit NX des CPU qui ont la feature selon l'e-mail sur la ML.
Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.
Tout a fait, pour avoir un semblant de protection sous x86 il faut passer par OpenBSD et peut-être (encore que tu as l'air de dire que pas trop) par VS.net.
Ceci étant est-ce que tu pourrais expliquer ou filer des infos ou des liens sur ce que font les fonctions de protections de segments sous VS.net ?
Kha
[^] # Re: Desole...
Posté par pasBill pasGates . Évalué à 5.
cf. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vc(...) pour plus d'infos
[^] # Re: Desole...
Posté par ckyl . Évalué à 4.
Linux : PaX, ExecShield, OpenWall (et d'autres)
OpenBSD/NetBSD : R^W
FreeBSD: rien niveau noyau sniff
Je pense pas que Solaris x86 fournisse quelque chose
Autrement au pire patchage gcc.
Bien sur faire du hardware en software ca a un certain cout :-)
[^] # Re: Desole...
Posté par ckyl . Évalué à 2.
Oui car les solutions pour x86 existent déjà dont exec shield écrit par le même ingo molnar.
[^] # Re: Desole...
Posté par itstimetogo . Évalué à 1.
En production depuis redhat 9.
[^] # Re: Desole...
Posté par ckyl . Évalué à 1.
"En production depuis redhat 9. "
Vous avez quoi a prouvez avec qui était le premier ? Y'avait aussi des solutions bien qu'avant exec shield pointe le bout de son nez enfin je vois pas l'apport au débat hormis le "moi je". C'est du niveau du thread de bugtraq que j'ai posté plus bas...
Autrement tu m'expliques comment la RH 9 est sortie fin Mars et execshield posté sur lkml debut mai (2003) ? Tu m'aurais dit FC1 ou REL 3 tu aurais été plus crédible à mes yeux.
[^] # Re: Desole...
Posté par itstimetogo . Évalué à 1.
La rumeur...
> Vous avez quoi a prouvez avec qui était le premier ?
C'est quoi qui te gène ? RedHat a fait exec-shield et l'utilise en premier. Ça doit rester une information confidentielle ?
> enfin je vois pas l'apport au débat hormis le "moi je".
C'est pas "moi je" mais "eux ils" ici.
exec-shield fait pratiquement la même chose que NX. Tu vois le rapport ?
Le rapport est qu'un programme qui tourne sous exec-shield tournera avec NX.
Des personnes se questionnent sur la mise en production de NX. Le fait qu'exec-shield soit utilisé depuis 1 an est une réponse concrête. J'ai indiqué sur quelle distribution. C'est grave ?
> Tu m'aurais dit FC1 ou REL 3 tu aurais été plus crédible à mes yeux.
Huuu.
Tout juste.
[^] # Re: Desole...
Posté par itstimetogo . Évalué à 0.
Comme Linux (ie si le processeur le supporte).
[^] # Re: Desole...
Posté par taiwan . Évalué à -3.
# Pardon ?
Posté par ckyl . Évalué à 10.
Heu pardon c'est serieux la ?
Bon y'a deux cas si y'a un support hardware ou non.
S'il y a support hardware cette chose existe depuis la nuit des temps. Sur les systèmes qui utilisent la segmentation ou sur des processeurs non moisis niveau pagination ceci a toujours existé aussi loin que la mémoire virtuelle remonte.
Pour pas remonter à la nuit des temps je sais que Solaris le supporte au moins depuis 1998. NetBSD le fait aussi sur toutes les architectures potables.
Autrement pour faire plus mal je dirais que les anneaux Multics basés sur des segments faisaient déjà cela... y'a un peu plus de 20 ans... (rha j'étais même pas né !)
Le problème est que quelques architectures bien merdiques on fait l'économie d'un ou deux bits par pte et qu'on est bien emmerder maintenant et qu'il faut des ruses de sioux au niveau noyau pour émuler ce que le processeur n'est pas capable de fournir. Au niveau du noyau même linux à en effet été l'un des premiers (c'est plus recent maintenant) notament avec PaX & co. Il existe un autre technique mais qui demande la recompilation des tout sur la machine les solutions noyaux ayant l'avantage d'etre transparente.
Le seul événement la dedans, même s'il est pas récent, c'est que la famille de proco la plus répendue va enfin être potable niveau VM. L'AMD 64 étant pas mal foutu si on excepte les 8 modes de compatibilités...
Bref les linuxiens sont en train de trop s'enfermer dans leur monde linux à mon gout :-)
[^] # Re: Pardon ?
Posté par Ontologia (site web personnel) . Évalué à 1.
C'est pas très propre tout ça...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pardon ?
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# W^X sur OpenBSD
Posté par Foxy (site web personnel) . Évalué à 10.
Avant de dire des conneries pareilles, tu pourrais te renseigner.
Sur OpenBSD, cette fonctionnalité s'appelle "W^X" (Write XOR Execute) et est dispo depuis la version 3.4.
Cela est supporté aisément sur les processeurs disposant de cette fonctionnalité en "natif" et au pris de pas mal de contorsions (d'après les dev) sur i386.
# Reflexion, extension
Posté par Prae . Évalué à 4.
Le modérateur n'aurait pas pu simplement supprimer cette phrase plutot que de rajouter une note ?
[^] # Re: Reflexion, extension
Posté par x0ra . Évalué à 1.
[^] # Re: Reflexion, extension
Posté par Prae . Évalué à 5.
J'ai plus l'impression de voir un tacle en bonne et du forme qu'une notification d'erreur sur la news.
Le modérateur aurait pu modifié la news pour mettre ceci à la place par exemple :
"Linux est l'un des OS à implémenter cette technologie"
[^] # Re: Reflexion, extension
Posté par tgl . Évalué à 4.
C'est vrai ça ? Ça me semble un peu absurde, le but du jeu étant d'avoir des niouzes de qualité, justes et lisibles... Si ça doit passez par des modifs ou reformulations, et bien soit, qui ça dérange ?
[^] # Re: Reflexion, extension
Posté par x0ra . Évalué à 0.
Ce n'est qu'une opinion personelle à moi que j'ai ... mais bon, un modéro modère, il n'a pas à reformuler les propos d'autrui.
[^] # Re: Reflexion, extension
Posté par 007 . Évalué à 0.
Et aussi des modérateurs qui sont là pour vérifier les news. Sinon ils ne sont plus utiles.
# Et la protection au niveau des segments alors ?
Posté par Guillaume Knispel . Évalué à 6.
Bref tout ca pour dire qu'avant de tripper sur des nouveautés loin d'être nouvelles, d'ailleurs, il faudrait ptet prendre le temps de matter l'existant et d'eviter de faire des choses absurdes au niveau design des OS (oui, la supperposition segment de code et segment de donnée est une chose ABSURDE, voir GRAVE si on prend en compte tous les exploit rendus possibles), et de venir se plaindre par apres du processeur sans même s'appercevoir de l'absurdite de sa plainte.
C'etait le coup de gueule du jour d'un psycopathe qui a les trois manuels d'Intel comme livre de chevet.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par daggett . Évalué à 9.
En dehors de la vision d'horreur que constituerait un retour à la mémoire segmentée, et tres certainement les complications au niveau de l'OS, et de toutes les applications (puisque sous Unix on a une vision lineaire de la RAM) (va-t-il falloir utiliser "far pointer" en plus de "pointer" ? :) ), l'impossibilité d'executer du code dans la pile ou le tas est toute relative.
Voila comment j'imagine les choses:
Si je ne m'abuse, pour exploiter un BufferOverflow, il fallait pouvoir:
1) placer du code quelque part (pile ou tas)
2) réécrire dans la pile le mot de 32 bits qui contient l'adresse de retour de la fonction, pour qu'elle pointe sur la zone 1)
La fin de toute fonction est normalement l'instruction RET qui dépile l'addresse EIP de retour et saute à cette adresse (dans le segment de code CS). Effectivement, separer CS de DS ou SS (les segment de donnée ou de pile) empeche de faire cela directement. Mais il existe une autre instruction, RETF (RET Far) qui dépile EIP et CS, et permet donc d'outrepasser la séparation de segments en changeant la valeur de CS.
Cette instruction, comme RET, est codée sur 1 octet (0xCB). Une analyse du binaire attaqué permet surement de trouver un octet de cette valeur quelque part dans le code, dont on puisse injecter l'adresse. À partir de là, la sequence d'attaque deviendrait:
1) placer du code quelquepart dans la pile ou le tas
2) réécrire dans la pile l'adresse de retour de fonction, pour qu'elle pointe vers un octet dans le segment de code, codant pour RETF
3) réécrire le double mot précédent de la pile, pour qu'il contienne le segment+adresse de la zone 1.
Le RET standard de la fonction va dépiler 2, et executer le RETF a l'adresse indiquée. Ce RETF va lui-meme dépiler la valeur dans 3, et faire un saut long vers la zone 1, en ayant modifié le segment de code CS.
C'est bien sur plus difficile comme attaque, mais je pense que ca reste possible.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par Guillaume Knispel . Évalué à 3.
Quand au retour en segmenté qui ferait faire des cauchemards, je ne vois vraiment pas ou est le problème : on est deja en mode segmenté : il y a un segment de code dans CS et un de données en DS, le truc c'est qu'ils ce recouvrent, et que le recouvrement rend donc inoperant une protection naturelle des x86. Moi je parlais de rassembler tout le code dans un coin de l'expace lineaire, toutes les données dans un autres, et que le segment de code n'inclue pas les données et reciproquement. Comme le segment de code est dans CS et est utilisé automatiquement par les jump, call, etc, ta pas besoin de préciser le segment. De meme pour les données : le segment de données est dans DS, et est utilisé automatiquement dans toutes les operations d'acces au données. Vu le modèle mémoire du C, il ne faudrait mieux pas separer le segment de données du segment de pile par contre (par contre en java on pourrait...), mais bon c'est pas essentiel de faire ca.
Bien evidemment faire ca aujourd'hui, meme si je pense que c'est possible, serait assez lourd : modification surrement toute la chaine de compilation et de chargement dynamique, du noyeau, puis recompilation. C'est pour ca que je disais que ca aurait du etre fait des le début. Reste que desactiver quasi volontairement une protection pour refaire la meme 10 ans apres a un autre niveau en plus compliqué, qui tourne sur peu de procs de la famille majoritaire x86 (alors que linus a developpé initialement sur x86), n'est pas tres (voir du tout) malin.
PS: evitez de me moinsser pendant 1 semaine, je viens de me recreer un compte et il m'est impossible de poster si j'ai trop peu de karma, encore un systeme de controle débile de merde, vu que j'ai voulu ecrire ca hier soir et que j'ai pas pu et que j'ai faillis refermer mon compte immédiatement sous la colere.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par ckyl . Évalué à 2.
Problème des bibliothèques partagées mais en gros c'est ce que semble faire W^X. Ils ont changé la ld pour que l'on puisse regrouper dans un coin les données et de l'autre le code.
http://groups.google.com/groups?q=g:thl3632333067d&dq=&hl=e(...)
Ca fait en effet pas mal de changements (plus aucun binaire compilé avant ne fonctionne) ce n'est donc plus facilement faisable surtout pour du desktop ou on commence a voir plein de trucs precompilés partout.
Le jeux est de savoir si *maintenant* c'est la peine de tout casser pour une architecture qui va pas tarder à partir à la poubelle. Tout comme est ce la peine de s'ennerver à supporter les big iron en x86 alors que des archis 64 bits plus adaptées sont maintenant abordables...
[À propos du malin]
Je pense surtout que le problème c'est qu'UNIX à toujours préféré la pagination et que malheureusement c'est le mauvais proco qui a gagné des parts de marché :-)
[^] # Re: Et la protection au niveau des segments alors ?
Posté par ckyl . Évalué à 5.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&thre(...)
Excellent thread sur bugtraq avec du Jedi/Sector one, du Theo de Raadt, du pageexec, du Solar Designer, du sauron, du Stealth qui parle comme des hommes qui mettent leur teub sur la table pour savoir qui a la plus grosse^W^W^Wfait un NX sur i386 en premier.
C'est rigolo à lire :-)
Bon autrement pour ce que tu proposes bien qu'etant pas specialiste de la chose il y a plusieur problème. Le problème est que les UNIX ont l'habitude de bosser avec un espace virtuel plat et a coup de pagination ca simplifie beaucoup les choses (cf les vieux threads sur lkml), la segmentation a totalement disparue de linux depuis le 2.2 il me semble et encore c'etait utilisé pour separer le mode noyau du mode utilisateur donc pas grand chose avoir avec le schmilbick.
ll y a des patchs qui se basent en effet sur la segmentation notament une des approches de PaX (http://66.102.9.104/search?q=cache:HYWR5K5BAXkJ:pax.grsecurity.net/(...) désole pour le google cache mais comme grsecurity est down ca aide pas pour avoir l'original) le principal problème c'est que tu coupes ton espace d'addressage en 2 à l'avance c'est pas top pour les machines "big iron".
Mes connaissances sont très limitées de ce coté mais commencer à faire mumuse avec plein de petits segments ca me semble pas etre la joie quand on est limité en nombre.
[^] # Re: Et la protection au niveau des segments alors ?
Posté par Guillaume Knispel . Évalué à 1.
J'imagine bien que ca pose quelques pb, sinon ca devrait etre fait aujourd'hui... Mais la question est : est-ce que ca pose plus de problème que ca n'en resoud ? Parce que le nombre d'exploit par buffer overflow est tout de meme impressionnant et aurait ete _tres_ reduit avec un tel systeme (je n'ose pas dire nul, j'ai peut etre oublie quelquechose...)
[^] # Re: Et la protection au niveau des segments alors ?
Posté par ckyl . Évalué à 2.
C'est déjà fait aujourd'hui, je pense que tu as vu au moins les deux implémentations que je t'ai montré. Il y a deux problèmes principaux cependant (en dehors des autres niveau sécurité).
SEGMEXEC casse l'espace d'addressage en 2 par defaut, si tu es en 3:1 il te reste 2 x 1.5 Go , si tu es en 2:2 il te reste 2 x 1 Go ca pose donc problème sur les machines blindées de RAM. La solution encore et toujours allez acheter un AMD64 ou n'importe quoi du style...
W^X explose tout les binaires existant, si c'est juste pour supporter le x86 je dirais que le jeux n'en vaut pas la chandelle étant donné que tout les concepteurs de proco ont l'air d'avoir compris le problème et avancent le fait que ca sera resolu dans les prochaines evolutions.
Si tu veux une comparaisons objective entre les deux ca va etre difficile etant donné la rivalité entre OpenBSD et PaX/Grsecurity et qu'ils ne savent que s'insulter. Tu as une comparaison là http://grsecurity.org/papers.php(...) par spender et sur misc@openbsd et bugtraq y'a quelques thread bien saignants.
[^] # PaX pour les x86 sans NX, NX pour les autres...
Posté par Guillaume Knispel . Évalué à 1.
Pour les pocesseurs de "vielles" machines sans NX, PaX ca à l'air bien, mangez en, on est jamais trop prudent coté sécurité !
Je vais d'ailleurs tester ce week end tellement j'aime utiliser intelligement mon materiel et ses protections naturelles :p
Bref tout ce thread pour dire que NX c'est bien beau, mais on savait deja faire avant à peu près pareil, et on pouvait deja techniquement depuis plus de 10 ans... (et me dites pas que j'aurais du m'y mettre et implementer ca moi même, j'etais trop petit ! :)
Quand à implementer quelque chose qui me semble naturel dès le début, à savoir une séparation code / donnée concrétisé par la segmentation correspondante et une chaine de compilation / chargement qui met tout là ou il faut, sans possibilité de passer outre, ce n'est bien evidemment plus possible puisqu'on est plus au début... Mais si quelqu'un dans l'assistance à envi de coder un OS je lui conseille vivement de le faire : à mon gout la sécurité est une priorité des plus grandes, et je ne pense pas que la sacrifier pour de petites simplifications soit une très bonne idée. D'autant que c'est ce mettre dans une situation ou il faudra peut être dans le futur faire des choses bien plus complexes pour corriger le tir !
# 2 drapeaux sinon rien...
Posté par Quzqo . Évalué à 7.
C'est curieux mais j'aurai plutôt pensé que l'économie imposerait un drapeau booléen execute/no execute.
Serait-ce une erreur de formulation de la dépêche, une bêtise d'ingénieur, une réalité électronique que j'ignore, un chipotage de ma part ou ces 4 états (drapeaux levés et baissés) laissent-ils présager d'autres possibilités ?
[^] # Re: 2 drapeaux sinon rien...
Posté par ckyl . Évalué à 8.
De plus le drapeau n'est pas vérifié à chaque accès mémoire mais on moment du chargement dans le TLB.
http://www.watson.org/~arr/pdfs/hw/amd64_vol2_system_programming.pd(...)
5.4.1 p 169
5.6.2 p 173
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.