Wenzel a écrit 8 commentaires

Je ne peux que confirmer vos commentaires malheureusement.

Je suis volontaire pour rapporter des bugs, mais si ils ne sont pas traités derrière, je ne veux plus m'impliquer dans ce process de qualité.

Et je ne me suis remis de juillet dernier, ou ils ont poussé une maj qui a fait explosé le driver Wifi.

Bug report évidemment: https://bugzilla.redhat.com/show_bug.cgi?id=1732165

et 2 semaines après, toujours aucun paquet pour corriger ce problème…

J'ai du trouver un câble ethernet dans l'urgence pour pouvoir faire un downgrade du paquet le soir-même.

Bonjour, et merci pour le feedback.

Mais si je m'en réfère à ton schéma d'architecture, cela me parait très ambitieux

C'est vrai que c'est un projet avec une échéance sur plusieurs années, au vu de la complexité des hyperviseurs, et de la difficulté à rationaliser leurs APIs dans une bibliothèque d'abstraction.

Néanmoins je maintiens qu'il s'agit de la route à suivre, car les interfaces de VMI se ressemblement, et les hyperviseurs finiront par offrir une API de VMI complète.

Le fait de pouvoir construire des applications (comme des stubs) sans se soucier de la couche en dessous est un vrai plus à mon sens.

Dans le même ordre d'idée, le projet Sandbagility est un framework d'introspection de VM Windows utilisé aussi pour faire du RE

Je connais ce framework, et l'ai évoqué dans mes slides :)
J'ai hâte de suivre ses prochaines évolutions.

Pour l'heure il ne répondait pas à mon problème, mais il apporte des briques de solutions !

On peut probablement écrire des fonctions pour les parcourir (avec tous les problèmes classiques de cohérence des infos si on regarde au moment où un thread est inséré/retiré).

il y a effectivement le cas ou l'ordonnanceur va mettre à jour l'état des processus et des threads, et il faut éviter de lire les structures task_struct pour Linux lorsque l'ordonnanceur tourne.

Avec des symboles et une connaissance du guest, c'est tout à fait faisable.

Pour influer sur l'ordonnanceur (et choisir à quel thread on donne la main), ça me semble vraiment difficile sans ajouter un support spécifique dans le noyau.

Il ne s'agit pas de forcer l'ordonnanceur à suivre un certain comportement.

L'objectif est de suivre son fonctionnement, et d'intercepter les appels à certaines fonctionnes cruciales,

comme switch_to (Linux) ou KiSwapThread (Windows), qui vont scheduler un nouveau thread pour execution, et reprendre la main à ce moment là.

Encore une fois, c'est la connaissance du guest via Rekall qui nous fournit l'emplacement de ces symboles, ainsi que les offsets des structures en mémoire.

Donc possible et pas (si) impossible que ça en à l'air au premier abord :)

J'oubliais de préciser que Slack ne fonctionne que sur invitation, je n'ai pas trouvé comment en faire un chat public.

Envoyez-moi un mail à mathieu.tarral@protonmail.com

J'ai également pensé à ce use case !

C'est pourquoi j'avais déjà intégré le calcul des checksum sur chaque inode ;)
https://github.com/Wenzel/oswatcher/blob/master/oswatcher/model.py#L28

Bien vu pour OSQuery
Query your devices like a database, ça semble déjà très proche de ce que j'essaye de faire.

J'avoue avoir vaguement entendu parler du projet il y a quelques années, en lisant une dépêche en diagonale, mais sans plus.
Egalement, le fait de pouvoir introspecter des VMs sans utiliser d'agent était un vrai bonus, puisque celà ne faussait pas la capture des caractéristiques, ni les futurs diffs.

Je vais regarder pour une intégration.

Merci !

L'objectif est de prendre un système d'exploitation, et de pouvoir traquer ses changements au cours des nouvelles releases qui sont sorties, aussi bien que celles qui appartiennent au passé.

Donc éventuellement partir d'une Ubuntu 10.04, et installer chaque nouvelle version jusqu'à la 18.10, en capturant leurs informations et caractéristiques respectives dans une base de donnée.

L'étape d'après et d'avoir une vue haut niveau sur ces données, et plus particulièrement de pouvoir comparer par exemple le filesystem d'une version par rapport à une autre (git diff), afin de mieux comprendre les ajouts et suppressions.

Il peut très bien s'agir d'une distribution GNU/Linux comme d'un Windows à mon sens, et l'on pourrait traquer les changements entre release, ou entre chaque mise à jour hebdomadaire !

J'espère avoir répondu à ta question.

Salut,

juste une petit typo, il s'agit vraisemblablement de kGraft, et non kGraph

;)