rencontrez le demon

December 2nd, 2007 par sbz

Alors qu’en ce jour où j’écris se passe une conférence ultra poilue en Italie (vous inquiétez pas on a notre envoyé spécial gaston sur place ) . La semaine dernière, s’est déroulée comme chaque année en Pologne la meetbsd 2007 au menu, des conférences bien advanced sur le debugging, dtrace, tor, les zones solaris, les nouvelles features de la branche FreeBSD 7.0 et un compte rendu des Google Summers Code NetBSD et FreeBSD. On regrettera juste que certaines ne sont pas traduite en anglais :(.

Lutins à vos papers!@#

Posté dans Article, FreeBSD, NetBSD | No Comments »

Répondre

Vous devez être identifié pour poster un commentaire.

Identification

SQUAD!

GCU live

[19:11:56] moid je ne vois pas en quoi ce serait plus simple avec un malloc sbrk qu'avec un malloc mmap.

[19:12:58] TheSnide non, mais le rincage au moment du munmap aj lieu de free

[19:13:20] TheSnide (autres == mmap)

[19:13:55] moid si tu rinces au moment de munmap(), ça ne sert à rien.

[19:13:58] TheSnide ... genre tu free() plus souvent que tu unmap

[19:14:27] moid d'une part parce que le munmap() fait disparaître la zone d'adresses, donc de toute façon un UAF va provoquer un SIGSEGV

[19:14:28] TheSnide bin si pour le destinatire du bloc

[19:15:07] TheSnide si tu re-mmap dans un autre process, tu leak

[19:15:11] moid d'autre part parce que pour les blocs plus petit qu'une page, il peut s'écouler beaucoup de temps entre l'appel à free() sur ce bloc et le numnmap() effectif de la page, qui contient d'autres allocations.

[19:15:13] TheSnide sinon

[19:15:45] moid quand tu re-mmap dans un autre process, le noyal aura initialisé la mémoire à zéro justement pour éviter que des données soient visibles d'un processus à l'autre.