Sygus.net

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - logiciel libre

Fil des billets - Fil des commentaires

dimanche, juin 8 2008

La mémoire sous Linux : cartographie de la mémoire

La version 2.6.25 du noyau Linux a vu l'apparition d'une série de patchs écrits par Matt Mackall, qui permettent de connaitre précisément le mapping entre les pages virtuelles et les pages physiques, et tout ceci au niveau userland. Cela se fait par l'intermédiaire des fichiers spéciaux /proc/PID/pagemap, /proc/kpagecount et /proc/kpageflags. Le premier indique les adresses des pages physiques utilisées par un processus précis. Le second montre, pour chaque page physique, le nombre de pages virtuelles qui pointent dessus. En effet, la pagination permet de faire correspondre à une même page physique plusieurs page virtuelles appartenant à des processus différents. Enfin, /proc/kpageflags permet de connaitre le statut d'une page mémoire, qui peut être une combinaison des flags suivants :

#define KPF_LOCKED     0
#define KPF_ERROR      1
#define KPF_REFERENCED 2
#define KPF_UPTODATE   3
#define KPF_DIRTY      4
#define KPF_LRU        5
#define KPF_ACTIVE     6
#define KPF_SLAB       7
#define KPF_WRITEBACK  8
#define KPF_RECLAIM    9
#define KPF_BUDDY     10

Avec toutes ces infos, il est possible d'établir une cartographie de l'utilisation de la mémoire vive. C'est ce que fait l'outil Pagemap-Demo, développé par le même auteur que ces patchs. Le graphique suivant montre la mémoire virtuelle d'un processus (en l'occurence, firefox). On peut voir le segment de code (le ptit truc tout en haut à gauche), ainsi que le tas (le rectangle du haut), le pile et les différentes librairies (en bas). La correspondance avec le nom des segments est faite en lisant les informations délivrées par le fichier /proc/PID/maps. Il suffit donc de survoler un segment pour connaitre à quoi il correspond et sur quelle adresse nous sommes.

/proc/PID/pagemap

Le graphique suivant représente le même processus, firefox, mais après avoir ouvert de nombreux sites web. Le jaune indique les pages les plus récemment ajoutées.

/proc/PID/pagemap

Maintenant, on passe à l'affichage d'une cartographie de la mémoire physique :

/proc/kpagecount

Enfin, on peut connaitre clairement comment la mémoire est utilisée :

/proc/kpageflags

  • En blanc : les objets utilisés par l'allocateur slab au sein du noyau.
  • En rose : les pages ayant le flag dirty activé.
  • En bleu : les pages utilisées par l'algorithme LRU (Least Recently Used).

Le patch permet également de connaitre la quantité de mémoire physique partagée entre différents processus ainsi que la mémoire physique utilisée uniquement par un processus. Ceci permet d'obtenir une nouvelle valeur, le PSS (Proportional Set Size), qui indique le nombre de pages mémoires divisé par le nombre de processus qui l'utilisent. Une information pertinente pour évaluer la quantité de mémoire utilisée par un processus.

samedi, juin 7 2008

SSTIC 2008 : la sécurité s'invite à Rennes

Frédéric Guihéry Le microcosme de la sécurité informatique avait rendez-vous les 4, 5 et 6 juin à l'université de Rennes 1 pour une nouvelle édition du SSTIC. L'occasion pour des personnes d'horizons divers d'échanger et de présenter leurs recherches. Comme chaque année, et ce depuis 6 éditions (la 3ème pour moi), l'équipe du SSTIC nous propose une brochette de conférences couvrant les principaux thèmes de la sécurité des systèmes d'information : un peu d'organisationnel et de juridique, des présentations de projets (ERESI, GenDbg, SinFP) et pas mal d'analyses techniques avec aussi bien de la crypto, de la virologie, du reverse que des attaques matérielles, applicatives ou systèmes. L'accent a été clairement mis sur les techniques d'analyses statique et dynamique de code avec des conférences sur des méthodes de rétroingénierie et de déboguage noyau/processus. Des techniques très intéressantes, qui servent aussi bien les intêrets des attaquants (compréhension des vulnérabilités en analysant les patchs de sécurité) que des défenseurs (analyse de malwares pour comprendre comment ils se propagent sur nos systèmes).

En vrac, les points à retenir (ou pas...) :

  • la possibilité de faire évader de l'information grace aux variations de la vitesse de rotation sur les ventilos des processeurs.
  • Debian en a pris pour son grade à propos de la faille OpenSSL.
  • ivanlef0u n'est pas un bot IRC.
  • le bus Firewire doit définitivement être supprimé sur les machines. Bon ok, l'accès à la mémoire physique par DMA n'est pas nouveau, mais les utilisations possibles sont assez sympas.
  • il faut tout faire pour éviter les zombies.
  • le piégeage de processeur offre pas mal de possibilités d'attaques. Mais bon, si on va dans ce sens, on peut imaginer tout un tas de backdoor matérielles. A mon sens, l'hypothèse de départ est quand même à la limite d'être réaliste.
  • stopper les grands réseaux d'envois de spams/malwares est une utopie à partir du moment ou certains domaines et/ou plate-formes d'hébergements se situent dans des zones juridiquemet inatteignables.
  • chez INL, ils s'amusent plutôt bien.
  • le patch pour l'attaque de -nikoteen est le suivant : "so strong, that I can't get through". Et ça marche !!

Un point important cette année, est la volonté de pas mal d'équipes de recherche de diffuser librement les sources de leurs projets. Je pense notamment aux projets ERESI et SinFP, de même qu'à plusieurs outils présentés pendant les rumps sessions. De plus, en regardant les portables présents dans le public, il est frappant de voir qu'un bon nombre utilisent des OS libre, typiquement Linux, avec une majorité de Debian et d'Ubuntu. Il est donc clair que la communauté du logiciel libre est plutôt bien représentée dans le monde de la sécurité. J'ai d'ailleurs croisé quelques têtes aperçues au FOSDEM et aux RMLL.

Plus généralement, il est intéressant de voir que la sécurité "ouverte", par opposition à la sécurité par l'obfuscation, est prédominante dans ce genre de conférence. Le logiciel libre a donc un rôle important à jouer, aussi bien pour assurer l'indépendance technologique d'un état ou d'une société vis-à-vis de solutions propriétaires étrangères, que pour permettre une maîtrise du code exécuté, ce qui est d'autant plus important pour des solutions de sécurité. Et quoi qu'en disent les détracteurs du logiciel libre, qui ne se privent pas de rappeler leurs limites comme dans le cas de la faille OpenSSL/Debian, il n'est pas certain qu'une boîte diffusant un logiciel propriétaire similaire aurait annoncé publiquement et aussi rapidement les détails et les implications d'une telle vulnérabilité. Laissant ainsi leurs utilisateurs dans la méconnaissance du risque qu'ils encourent.

Le contexte légal et politique s'est également fait sentir lors de ce SSTIC, mais moins que l'an dernier, avec quelques remarques et questions du public concernant notamment les limitations que la loi nous impose quant aux investigations sur des binaires. En effet, la loi n'autorise le desassemblage que dans une optique d'intéropérabilité logicielle... et même pas matérielle (!). A ce sujet, je me demande si l'auteur d'un malware peut attaquer en justice une boîte qui aurait desassemblé son programme afin d'en étudier son mécanisme... Bref, qu'en est-il des labo de recherche par exemple chez EADS ou au Celar et de leur légitimité à faire du reverse ? Les intervenants du Celar ont malheureusement rapidement éludé la question.

Finalement, nous avons eu un SSTIC très bien organisé (avec une amélioration notable de l'enregistrement du mecredi matin !), une très bonne ambiance, que se soit pendant les confs, pendant les rumps ou lors du social event. Dommage que beaucoup soient repartis sur Paris rapidement, car la soirée du vendredi soir était... mémorable :)

vendredi, avril 25 2008

La mémoire sous Linux : analyse du fichier /proc/meminfo

Dans cet article, je vais tenter d'expliquer les différentes informations que le noyau Linux nous donne au travers du fichier /proc/meminfo. Comme support, je vais afficher les données qui concernent mon système. Il s'agit d'un noyau 2.6.24-1 dans une Debian unstable. Ma machine repose sur une architecure x86 en 32 bits et contient une barrette de 1 Go de mémoire RAM.

$ cat meminfo 
MemTotal:      1036256 kB
MemFree:        191256 kB
Buffers:         51824 kB
Cached:         468392 kB
SwapCached:           0 kB
Active:         398852 kB
Inactive:       404108 kB
HighTotal:      131008 kB
HighFree:          256 kB
LowTotal:       905248 kB
LowFree:        191000 kB
SwapTotal:      524280 kB
SwapFree:       524280 kB
Dirty:              44 kB
Writeback:           0 kB
AnonPages:      282736 kB
Mapped:          82108 kB
Slab:            22552 kB
SReclaimable:    14468 kB
SUnreclaim:       8084 kB
PageTables:       2232 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1042408 kB
Committed_AS:   880596 kB
VmallocTotal:   114680 kB
VmallocUsed:      7540 kB
VmallocChunk:   105972 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB

Commençons par les premières lignes :

  • MemTotal : la quantité de mémoire vive utilisable (ma barrette fait 1 Go (1 073 742 Ko), mais il y a quelques Mo réquisitionnés par le noyau (visiblement 12 615 Ko)).
  • MemFree :la quantité de mémoire vive actuellement non allouée.
  • Buffers : la quantité de mémoire vive actuellement allouée dans des buffers.
  • Cached : la quantité de mémoire actuellement utilisée en tant que cache (par exemple, des caches pour les transferts vers et depuis le disque dur).
  • SwapCached : la quantité de mémoire actuellement sortie du swap, mais dont une copie est toujours présente dedans.
  • Active : la quantité de mémoire vive récemment utilisée.
  • Inactive : la quantité de mémoire qui n'a pas été utilisée depuis un certain temps (le noyau pioche d'abord dans ces pages s'il a besoin de mémoire).

Sur une architecture x86 32 bits, la mémoire physique est séparée en trois zones. D'une part, la zone ZONE_DMA, qui correspond aux adresses physiques de 0 à 16 Mo. D'autre part, la zone ZONE_NORMAL qui va de 16 à 896 Mo. Et enfin, la zone ZONE_HIGHMEM qui va de 896 à 4 Go (voire 64 Go avec l'extension PAE). Sur ma machine, la mémoire vive remplie donc les 2 premières zones, plus une partie de la ZONE_HIGHMEM.

  • HighTotal : la quantité de mémoire vive présente dans la zone ZONE_HIGHMEM.
  • HighFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_HIGHMEM.
  • LowTotal : la quantité de mémoire vive présente dans le zone ZONE_NORMAL.
  • LowFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_NORMAL.

Vérifions :

HighTotal + LowTotal = 131008 + 905248 = 1036256 = MemTotal
HighFree + LowFree = 252 + 57468 = 57720 = MemFree

Chouette, ça colle !

  • SwapTotal : la taille du swap.
  • SwapFree : la place disponible dans le swap.

Dans mon cas, le swap n'est pas du tout utilisé (en effet, OpenOffice n'est pas encore lancé... :). C'est également vérifiable avec l'utilitaire swapon :

$ sudo swapon -s
Filename           Type        Size    Used Priority
/dev/mapper/lvm-swap  partition  524280   0   -1
  • Dirty : la quantité de mémoire en attente d'être écrite sur le disque.
  • Writeback : la quantité de mémoire qui est actuellement en train d'être écrite sur le disque.
  • AnonPages : la quantité de mémoire allouée avec la fonction mmap() avec le flag MAP_ANONYMOUS.
  • Mapped : la quantité de mémoire allouée avec la fonction mmap() à partir de fichiers ou de devices.
  • Slab : la quantité de mémoire utilisée au sein du noyau, et allouée avec l'allocateur Slab, pour ses propres objets et structures.
  • PageTables : la quantité de mémoire utilisée en tant que table de pages pour gérer la pagination.
  • CommitLimit : une estimation de la quantité maximale de mémoire disponible pour être allouée.

Linux sépare la mémoire virtuelle en deux partie. Une première, de 3 Go, et qui contient l'espace d'adressage virtuel d'un processus. La seconde, qui elle fait 1 Go, et qui contient l'espace d'adressage noyau. C'est dans cet espace que seront mappés les zones ZONE_DMA et ZONE_NORMAL. Or, celles-ci ont une taille maximale cumulée de 896 Mo. Il est donc nécessaire d'avoir un autre espace, l'espace d'adressage virtuel du noyau, qui permet d'atteindre les 1 Go évoqués juste avant. La valeur VmallocTotal donne la taille de cet espace.

  • VmallocTotal : la quantité totale de mémoire de l'espace d'adressage virtuel du noyau.
  • VmallocUsed : la quantité de mémoire utilisée dans l'espace d'adressage virtuel du noyau.
  • VmallocChunk : le plus grand bloc contigu de mémoire virtuelle (et non physique) disponible dans l'espace d'adressage virtuel du noyau.
  • HugePages_Total : le nombre de hugepage allouée. Une hugepage est une page d'une grande taille (sisi :), utilisée par des programmes qui ont des besoins précis de mémoire.
  • HugePages_Free : le nombre de hugepage disponibles.
  • Hugepagesize : la taille d'une hugepage.

lundi, juillet 16 2007

RMLL - Le logiciel libre s'impose en France

[ Article paru sur Rue89 ]

Du 10 au 14 juillet, avaient lieu à l'université d'Amiens les rencontres mondiales du logiciel libre, connues également sous le diminutif RMLL. Une grande manifestation qui rassemblait, pour la 8ème édition, les différents acteurs du domaine. Ici, le monde associatif côtoie le monde de l'entreprise, le monde universitaire, le monde éducatif, les collectivités locales, les grandes administrations ainsi que les simples utilisateurs comme les passionnés. Bref, une vaste communauté où chacun y trouve son intérêt et tiens compte de l'intérêt des autres. Car c'est bien ça le logiciel libre : tout le monde a la liberté de contribuer, et chacun dispose des contributions des autres. Le parallèle avec l'encyclopédie Wikipédia est inévitable. D'ailleurs, les deux communautés sont très proches et sont liées par une même philosophie, celle du partage et de la création de biens communs.

Lire la suite...

jeudi, mars 8 2007

OLPC : how about security ?

During the last week of February, I spent three days in Brussels, for the FOSDEM event. This is the biggest european meeting about free and open source software and it was the second time I went there (the first one was in 2005). The first track I had the chance to see, and not the least, was about the project One Laptop Per Child (known as OLPC). A project which has the ambition to propose a laptop for each child in the development world. The cost, 100$ per computer, would be paid by countries, societies and international organizations. A huge project in fact, because the product is not only seen as a way to make profit (for the campanies involved), but has for aim to provide a tool "desgned for learning learning". By this way, it might be able for them to get the knowledge to develop themself.

Lire la suite...