que nvidia optimise son SDK pour ces cartes je le comprends (qu'il est pas envie de tester/optimiser leur code sur des cartes concurrentes), par contre que Nvidia fasse l'inverse, c'est a dire rajouter sciemment du code pour que le résultats soient ralenties sur les cartes concurrentes j'y crois moins, y a trop de risque de perte d'image de la marque si l'info fuite.
C'est pas un peu du FUD ça ?
Dans ton premier lien, y a rien qui parle de la licence MIT et dans le deuxième il y a rien qui dit que c'est la licence du "diable". Tu fait le même procès d'intention à jQuery ou Symfony (exemple tiré de ton deuxième lien qui utilise aussi du MIT)?
Oui, il n'y a pas de virtualisation dans docker donc le conteneur windows sur linux ou l'inverse c'est pas possible. Ce que les Windows conteneur sont c'est des API Windows (donc pas grand chose à voir avec les namespaces, capabilities, etc…) mais avec comme client "au niveau" Docker.
Je connaissais pas Xpra, si je comprend bien chaque conteneur à son serveur X à l'intérieur et Xpra sert de "proxy", j'ai bon ou je suis complètement à coté de la plaque ?
C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?
Effectivement docker et systemd sont en conflit ouvert je dirais, voir à ce sujet le dernier billet sur LWN.
Après dire que la plateforme sous jacente n'est plus importante n'est pas forcément faux, si tu passe tout dans des conteneurs tu te moque de la plateforme (modulo la version de ton kernel). Y en a qui ont appliqué ce principe à l’extrême c'est rancherOS (http://rancher.com/rancher-os/) ou tu te retrouve sur un système ou tu as juste un docker "système" et un docker "user" et rien d'autre, tous le reste tourne dans des conteneurs.
On verra qui gagne la bataille du conteneur entre systemd et docker mais je dirais que pour l'instant docker à une longueur d'avance pas sur le plan technique car effectivement l'approche daemon n'est pas la meilleur mais niveau eco-system/buzz ils sont loin devant. Le fait que les Windows conteneur utilisent l'API Docker c'est plutôt impressionnant je trouve. Et docker Inc travaille sur une approche non daemon aussi , ça s'appelle containerd (https://github.com/docker/containerd).
Historiquement Docker était une surcouche à LXC, jusqu’à la version 0.7 si mais souvenirs sont bons.
Et puis le développeur de docker ont eu pas mal d’écueils avec LXC, pas les même version suivant les distributions, des cassage d'API/ABI trop souvent et pas documenté et ils ont alors décidés d'implémenter leur propre solution en Go.
Et en dessous de libcontainer maintenant tu as runC (https://blog.docker.com/2015/06/runc/) qui est uniquement le runtime de container (sans toute la tuyauterie réseaux ). runC est du code Docker qui a était donné au projet Open Container Format de la linux fondation (dont docker est membre). C'est une réponse au "pseudo-standard" Rocket/Appc fait par CoreOS.
Y a aussi Ubuntu qui tente de vivre de son sponsoring de LXC en créant LXD.
Ceci n'est qu'une première étape puisque avec l'architecture actuelle de docker (daemon), le namespace user est le meme pour l'ensemble des conteneurs. Tu peux dire UID O du conteneur et l'UID 10049 à l'extérieur du conteneur mais ce mapping ce fera pour l'ensemble des conteneurs.
Cette fonctionnalité arrive tard dans docker par rapport à LXC par exemple qui le gère depuis longtemps. Ceci est lié au fait que docker étant basé sur du Go (golang), il a fallut attendre que les syscalls permettant d'activer les usernamespace soit implémenté dans ce langage, ce qui est arrivé avec le version 1.4 de Go. Ensuite la limitation proposé par l'architecture daemon a pas mal fait réfléchir les dévellopeurs sur la meilleur stratégie à appliquer. Voir ici un excellent résumé : http://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf
Il y a une deuxième feature de sécurité apporté par la version 1.10 qui j'attendais depuis très longtemps, c'est l'intégration par défaut de seccomp. Voir ici : https://github.com/docker/docker/blob/master/docs/security/seccomp.md
La on a vraiment une "power feature" je trouve, les users namespace c'est sympa mais ça va pas changer grand chose à ma vie (mes conteneurs ont tous un utilisateur non root et les binaires à l'intérieur de mes conteneurs n'ont pas de setuid).
L'IPV6 est pour moi un mauvais nom technique, c'est un peu comme HTML5, y a beaucoup de chose derrière.
L'IPV6 n'est pas seulement un nombre d'augmentation du nombre d’octet de l’adresse, y a des changements dans ICMP, ARP a été remplacé par NDP (Neighbor Discovery Protocol), l'autoconfiguration des addresses ip à changé aussi (Auto-configuré depuis la mac ou Route advertissement et/ou DHCPv6). Donc y a pas mal de chose à revoir et à réapprendre et malheureusement ceci est encore très mal, voir pas du tout enseigné dans les écoles.
Et le frein principale est aussi le coût. Maintenir la double stack (ipv4 et ipv6) dans son réseau à un coût. Surtout que le support de la double stack sera très certainement très très long. Même dans 20 ans je pense qu'on aura encore pas mal d'ipv4 en terminaison des réseaux (après le coeur du reseau sera peut etre passé en full ipv6 avec des tunnels).
J'ai rien compris à la dépêche, tu donne une lien pour DAFT et nous présente que PAR. C'est quoi le rapport entre les deux ? PAR c'est le protocol et DAFT l'outil ?
J'ai regardé vite fait le readme de github, je vois une dépendance zeromq, faut des noeuds zeromq sur toutes les machines ?
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
le deuxième lien décrit assez bien le problème.
Un problème de "fuite(leak)" d'un compteur dans du code kernel contrôlable facilement par syscall (tu peux incrémenter un compteur sans que les objets qu'est sensé compter se compteur existent). Le compteur est codé sur 32 bits (quelque soit l'architecture 32 ou 64 bit), donc si tu arrive à "overflow" le compteur (tu fait un tour de boucle et donc passe ton compteur à 0), le kernel croit qu'il n'y a plus d'objet référencé et va donc dés-allouer un emplacement mémoire. (use after free attack). Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Suffit alors de ré-allouer l'emplacement mémoire par du code user-space qui va appeler la fonction kernel suivante :
commit_creds(prepare_kernel_cred(0));
Cette fonction aura pour but de te donner l'uid et guid 0 à ton process. (ret2usr attack)
Ré-allouer le même emplacement mémoire est assez simple, l'allocateur mémoire SLAB du kernel linux est facilement prédictible. Pour des raisons de performance si tu demande une allocation d'un bloc mémoire de même taille juste après un dés-allocation, par soucis de performance (et pour pas se prendre la tête et éviter de la fragmentation mémoire), le noyau va te redonner le même emplacement mémoire.
Reste plus qu'a déclencher un syscall, (pour rappel syscall = exeption, passage en ring 0 (kernel)), qui va alors utilisé ton code userspace à toi, qui va appeller la fontion commit_creds.
Voila pour l'explication grosse maille, dans les faits l'exploit est un peu plus élaborer, puisque du code décrementant le compteur utilise le mécanisme de RCU (read copy update) et il est donc plus difficile de savoir quand on a réellement fait l'overflow du compteur. ça demande des synchro a grand coup de sleep. (donc leur exploit prend environ 30 min sur un coeur I7 pour passer root).
Il y a pas mal de mécanisme qu'on peut mettre en place pour se protéger de se genre d'attaque (se protéger du ret2user attack). https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf
1) La proposition impossible car complétement anti-performante :
Faire une séparation entre la mémoire user et kernel (arreté de mapper la mémoire kernel dans tous les processus user) et faire un context switch à chaque syscall.
Facile à faire mais complétement irréaliste car ça tuerai toute performance.
2) Identifier les zones mémoires ne devant pas s'exécuter en ring 0 :
Plusieurs techniques soft et aussi hard tels que PaX's KERNEXEC and UDEREF ou PXN (Priviligied Never Execute) sur ARM64.
3) empêcher l'appel à la fonction kernel commit_creds (l'appel ce fait par symbole).
Le symbole (l'emplacement mémoire de la fonction) est facilement connaissable (définie statiquement à la compilation et dépend uniquement de l'architecture utilisée et du compilateur (gcc ici)). Suffit de mettre de l'aléatoire en place à travers la technique de KASLR (Kernel Address Space Layout Randomisation). Dans ce cas il faut alors éviter de laisser des informations fuitées sur l'emplacement des symboles (voir par example kptr_restrict pour censurer /proc/kallsyms).
Voila ce que j'en ai compris (ps: je suis pas expert en sécurité donc il y a certainement quelques raccourcies).
J'utilise Mesos pour gérer mon déploiement de containeurs docker, il s'occupe alors lui même de supprimer les containers qui ne sont plus utilisés (voir l'option --docker_remove_delay).
Parler d'un vrai système de fichier en réseau alors que c'est implémenté en userpace (basé sur FUSE) et dire que ça tiens la comparaison avec NFS faut oser. Niveau perf c'est le jour et la nuit, dès que ta plein de petits fichiers les performances s'écroulent. SSHFS c'est juste pas la bonne architecture (comme tout ce qui est basé sur FUSE), c'est rigolo pour s'amuser mais niveau perf c'est pas bon.
J'ai toujours trouvé bizarre l'idée d'associer dans un même outil, la gestion des dépendances et la gestion de code source (espace de travail). Ce que je veux dire par la, c'est que pour gérer mon espace de travail qui est composé de plusieurs git, j'utilise un outils dédié (dans mon cas l'outil repo d'android). De plus avec git-lfs ce n'est plus un problème de versionner aussi ses binaires à travers git. Ceci me permet de régénérer n'importe où ma base de code et ceci quelque soit le langage de programmation. Ensuite suivant le langage la partie gestion de dépendance de build et de runtime est géré par le système de build que je choisie.
En C/C++, pour un petit projet, j'aime assez bien la syntaxe android (android.mk).
Pour des projets plus complexes et devant intégrer plusieurs code open-source (qui viennent chacun avec leur système de build), j'utilise le "meta-build-system" yocto mais en prenant soins d'écrire une majorité de mes recettes en utilisant la bbclass "externalsrc" ou avec un git local.
Merci pour le lien vers peru que je ne connaissais pas. Néanmoins il à l'air d'utiliser git submodules, ce dont je ne veux pas. je veux juste un repo avec deux trois options supplémentaire et quand je regarde le code source de repo (python et orienté objet sans aucune doc) bah je me dis que je ferais mieux de partir from scratch avec un script bash pour la "hackabilité" de la chose et le coté zéro dépendance. Après go pourrait être une alternative intéressante aussi.
Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.
Effectivement je voudrais remplacer repo par gws.
Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).
Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.
Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).
Le prochain est intéressant, j'ai l'idée de faire la meme chose qui trotte dans ma tete depuis pas mal de temps a force d'utiliser les manifests repo d'android pour gérer mes workspaces et trouver certaines limitations dans cette outils.
Le choix de faire du bash est vraiment un bon choix je trouve, pour ce genre d'outil je veux avoir le minimun de dépendances. Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.
Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.
Deux autres fonctionnalités que j'aimerai voir implémenter (et qui celle la n'est pas dans repo) c'est :
1 la possibilité de choisir ces options de clone/fetch (je veux clonner certains gits en mode bare-metal, d'autre en mode shallow etc…)
2 la possibilité de rajouté un post hook, je vais un gws qui va me générer un workspace, qui va ensuite automatiquement m'appeler un script qui est dans mon workspace. C'est vraiment utile pour versionner des installeur sur lequel on a pas la main.7
En tout cas bravo pour le job. Faudrait que je trouve le temps d'y contribuer un peu.
En un poil plus bourrin tu fais tourner un conteneur docker dans lequel tu as ton VPN et ton appli qui l'utilise.
C'est un peu plus bourrin car tu fera aussi du namespace PID, cgroup en plus du namespace réseau … Mais tu te pausera moins de question puisque c'est l'outil docker qui s'occupera de configurer ton réseau à ta place . Tout dépend de ce que tu veux maîtriser.
[^] # Re: la backdoor est toujours là
Posté par Tangi Colin . En réponse au journal Nvidia ouvre son SDK GameWorks. Évalué à 7.
que nvidia optimise son SDK pour ces cartes je le comprends (qu'il est pas envie de tester/optimiser leur code sur des cartes concurrentes), par contre que Nvidia fasse l'inverse, c'est a dire rajouter sciemment du code pour que le résultats soient ralenties sur les cartes concurrentes j'y crois moins, y a trop de risque de perte d'image de la marque si l'info fuite.
[^] # Re: Hôpital … charité
Posté par Tangi Colin . En réponse au journal Sale temps pour les informaticiens lanceurs d'alerte. Évalué à 7.
L'affaire va faire du bruit, j'espère que le lanceur d'alerte viré sans sortira pas trop mal au prud'homme.
# Windows utilise meme du linux en interne sur les routeurs Azure
Posté par Tangi Colin . En réponse au journal Bookmark : Microsoft vend du Linux. Évalué à 2.
En dehors du sujet mais vu que certains s'étonne que Microsoft aime linux en 2016, voici une autre info.
Les routeurs azure de microsoft tourne sur du linux et il communique dessus:
https://azure.microsoft.com/en-us/blog/microsoft-showcases-the-azure-cloud-switch-acs/
[^] # Re: Microsoft a changé... ou pas.
Posté par Tangi Colin . En réponse au journal Microsoft rejoint la Fondation Eclipse et passe en open-source certains de ses plugins. Évalué à 4.
C'est pas un peu du FUD ça ?
Dans ton premier lien, y a rien qui parle de la licence MIT et dans le deuxième il y a rien qui dit que c'est la licence du "diable". Tu fait le même procès d'intention à jQuery ou Symfony (exemple tiré de ton deuxième lien qui utilise aussi du MIT)?
[^] # Re: Facile!
Posté par Tangi Colin . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 1.
Oui, il n'y a pas de virtualisation dans docker donc le conteneur windows sur linux ou l'inverse c'est pas possible. Ce que les Windows conteneur sont c'est des API Windows (donc pas grand chose à voir avec les namespaces, capabilities, etc…) mais avec comme client "au niveau" Docker.
Donc sur Windows pour lancer un conteneur Windows je fait un
docker run … comme sur mon linux quoi, après entre les deux pas grand chose à voir, c'est juste une compatibilité de l'API docker pour gérer des "conteneurs".
Voir par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/about_overview
Et c'est déjà la, sur du windows server 2016, bon tout tourne pas encore avec, ça me parait assez loin d'être production ready mais c'est disponible. Un petit résumé par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/reference/app_compat
# Xpra
Posté par Tangi Colin . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 1.
Je connaissais pas Xpra, si je comprend bien chaque conteneur à son serveur X à l'intérieur et Xpra sert de "proxy", j'ai bon ou je suis complètement à coté de la plaque ?
C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?
[^] # Re: Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 5.
Effectivement docker et systemd sont en conflit ouvert je dirais, voir à ce sujet le dernier billet sur LWN.
Après dire que la plateforme sous jacente n'est plus importante n'est pas forcément faux, si tu passe tout dans des conteneurs tu te moque de la plateforme (modulo la version de ton kernel). Y en a qui ont appliqué ce principe à l’extrême c'est rancherOS (http://rancher.com/rancher-os/) ou tu te retrouve sur un système ou tu as juste un docker "système" et un docker "user" et rien d'autre, tous le reste tourne dans des conteneurs.
On verra qui gagne la bataille du conteneur entre systemd et docker mais je dirais que pour l'instant docker à une longueur d'avance pas sur le plan technique car effectivement l'approche daemon n'est pas la meilleur mais niveau eco-system/buzz ils sont loin devant. Le fait que les Windows conteneur utilisent l'API Docker c'est plutôt impressionnant je trouve. Et docker Inc travaille sur une approche non daemon aussi , ça s'appelle containerd (https://github.com/docker/containerd).
[^] # Re: Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 5.
Historiquement Docker était une surcouche à LXC, jusqu’à la version 0.7 si mais souvenirs sont bons.
Et puis le développeur de docker ont eu pas mal d’écueils avec LXC, pas les même version suivant les distributions, des cassage d'API/ABI trop souvent et pas documenté et ils ont alors décidés d'implémenter leur propre solution en Go.
Maintenant la "full picture" est plus complète, docker c'est l'API haut niveau qui est compatible avec plusieurs "backend", par défault ça utilise "libcontainer" mais tu peux aussi explicitement spécifier d'utiliser LXC ou LMCTFY (https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/). Et même un backend Windows maintenant (https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_docker).
Et en dessous de libcontainer maintenant tu as runC (https://blog.docker.com/2015/06/runc/) qui est uniquement le runtime de container (sans toute la tuyauterie réseaux ). runC est du code Docker qui a était donné au projet Open Container Format de la linux fondation (dont docker est membre). C'est une réponse au "pseudo-standard" Rocket/Appc fait par CoreOS.
Y a aussi Ubuntu qui tente de vivre de son sponsoring de LXC en créant LXD.
La prochaine "feature" de Docker qui risque de faire du bruit c'est un meilleur support du Checkpoint/Restore (http://linuxplumbersconf.org/2015/ocw//system/presentations/2619/original/2015-08-20-CRIU_Support_in_Docker_for_Native_Checkpoint_and_Restore.pdf).
# Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 10.
Ceci n'est qu'une première étape puisque avec l'architecture actuelle de docker (daemon), le namespace user est le meme pour l'ensemble des conteneurs. Tu peux dire UID O du conteneur et l'UID 10049 à l'extérieur du conteneur mais ce mapping ce fera pour l'ensemble des conteneurs.
Cette fonctionnalité arrive tard dans docker par rapport à LXC par exemple qui le gère depuis longtemps. Ceci est lié au fait que docker étant basé sur du Go (golang), il a fallut attendre que les syscalls permettant d'activer les usernamespace soit implémenté dans ce langage, ce qui est arrivé avec le version 1.4 de Go. Ensuite la limitation proposé par l'architecture daemon a pas mal fait réfléchir les dévellopeurs sur la meilleur stratégie à appliquer. Voir ici un excellent résumé : http://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf
Il y a une deuxième feature de sécurité apporté par la version 1.10 qui j'attendais depuis très longtemps, c'est l'intégration par défaut de seccomp. Voir ici : https://github.com/docker/docker/blob/master/docs/security/seccomp.md
La on a vraiment une "power feature" je trouve, les users namespace c'est sympa mais ça va pas changer grand chose à ma vie (mes conteneurs ont tous un utilisateur non root et les binaires à l'intérieur de mes conteneurs n'ont pas de setuid).
[^] # Re: Qu'est-ce qui freine la migration à l'IPv6 ?
Posté par Tangi Colin . En réponse au journal Des abonnés Free reçoivent ¼ d’adresse IP. Évalué à 6.
L'IPV6 est pour moi un mauvais nom technique, c'est un peu comme HTML5, y a beaucoup de chose derrière.
L'IPV6 n'est pas seulement un nombre d'augmentation du nombre d’octet de l’adresse, y a des changements dans ICMP, ARP a été remplacé par NDP (Neighbor Discovery Protocol), l'autoconfiguration des addresses ip à changé aussi (Auto-configuré depuis la mac ou Route advertissement et/ou DHCPv6). Donc y a pas mal de chose à revoir et à réapprendre et malheureusement ceci est encore très mal, voir pas du tout enseigné dans les écoles.
Et le frein principale est aussi le coût. Maintenir la double stack (ipv4 et ipv6) dans son réseau à un coût. Surtout que le support de la double stack sera très certainement très très long. Même dans 20 ans je pense qu'on aura encore pas mal d'ipv4 en terminaison des réseaux (après le coeur du reseau sera peut etre passé en full ipv6 avec des tunnels).
# Besoin de plus d'info
Posté par Tangi Colin . En réponse au journal première sortie de "DAFT Allows File Transfers". Évalué à 10.
J'ai rien compris à la dépêche, tu donne une lien pour DAFT et nous présente que PAR. C'est quoi le rapport entre les deux ? PAR c'est le protocol et DAFT l'outil ?
J'ai regardé vite fait le readme de github, je vois une dépendance zeromq, faut des noeuds zeromq sur toutes les machines ?
Bref ça manque clairement d'informations.
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 3.
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
```
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 10. Dernière modification le 20 janvier 2016 à 21:05.
le deuxième lien décrit assez bien le problème.
Un problème de "fuite(leak)" d'un compteur dans du code kernel contrôlable facilement par syscall (tu peux incrémenter un compteur sans que les objets qu'est sensé compter se compteur existent). Le compteur est codé sur 32 bits (quelque soit l'architecture 32 ou 64 bit), donc si tu arrive à "overflow" le compteur (tu fait un tour de boucle et donc passe ton compteur à 0), le kernel croit qu'il n'y a plus d'objet référencé et va donc dés-allouer un emplacement mémoire. (use after free attack). Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Suffit alors de ré-allouer l'emplacement mémoire par du code user-space qui va appeler la fonction kernel suivante :
commit_creds(prepare_kernel_cred(0));
Cette fonction aura pour but de te donner l'uid et guid 0 à ton process. (ret2usr attack)
Ré-allouer le même emplacement mémoire est assez simple, l'allocateur mémoire SLAB du kernel linux est facilement prédictible. Pour des raisons de performance si tu demande une allocation d'un bloc mémoire de même taille juste après un dés-allocation, par soucis de performance (et pour pas se prendre la tête et éviter de la fragmentation mémoire), le noyau va te redonner le même emplacement mémoire.
Reste plus qu'a déclencher un syscall, (pour rappel syscall = exeption, passage en ring 0 (kernel)), qui va alors utilisé ton code userspace à toi, qui va appeller la fontion commit_creds.
Voila pour l'explication grosse maille, dans les faits l'exploit est un peu plus élaborer, puisque du code décrementant le compteur utilise le mécanisme de RCU (read copy update) et il est donc plus difficile de savoir quand on a réellement fait l'overflow du compteur. ça demande des synchro a grand coup de sleep. (donc leur exploit prend environ 30 min sur un coeur I7 pour passer root).
Il y a pas mal de mécanisme qu'on peut mettre en place pour se protéger de se genre d'attaque (se protéger du ret2user attack). https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf
1) La proposition impossible car complétement anti-performante :
Faire une séparation entre la mémoire user et kernel (arreté de mapper la mémoire kernel dans tous les processus user) et faire un context switch à chaque syscall.
Facile à faire mais complétement irréaliste car ça tuerai toute performance.
2) Identifier les zones mémoires ne devant pas s'exécuter en ring 0 :
Plusieurs techniques soft et aussi hard tels que PaX's KERNEXEC and UDEREF ou PXN (Priviligied Never Execute) sur ARM64.
Cette protection peut malheureusement aussi être contourner si on arrive à utiliser la zone mémoire physmap (voir https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf). Mais on complique déjà la vie des attaquant avec ces protections.
3) empêcher l'appel à la fonction kernel commit_creds (l'appel ce fait par symbole).
Le symbole (l'emplacement mémoire de la fonction) est facilement connaissable (définie statiquement à la compilation et dépend uniquement de l'architecture utilisée et du compilateur (gcc ici)). Suffit de mettre de l'aléatoire en place à travers la technique de KASLR (Kernel Address Space Layout Randomisation). Dans ce cas il faut alors éviter de laisser des informations fuitées sur l'emplacement des symboles (voir par example kptr_restrict pour censurer /proc/kallsyms).
Voila ce que j'en ai compris (ps: je suis pas expert en sécurité donc il y a certainement quelques raccourcies).
[^] # Re: Bof
Posté par Tangi Colin . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 5.
Tu raisonne serveur mais si tu pense aux rootkit android la faille est déjà beaucoup plus sérieuse.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Tangi Colin . En réponse au journal Adieu Biicode, bonjour Conan. Évalué à 1.
Docker fonctionne très bien avec des applis graphique, vu juste pensé à "binder" la socket Xorg du "host" au lancement de son conteneur.
[^] # Re: Verrouillage?
Posté par Tangi Colin . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 4.
si ton problème c'est d'héberger une instance de github sur ta propre machine tu peux le faire, ils ont des offres payantes qui permettent cela.
# Mesos comme ramasse-miette
Posté par Tangi Colin . En réponse au journal Un ramasse-miette pour docker. Évalué à 3.
J'utilise Mesos pour gérer mon déploiement de containeurs docker, il s'occupe alors lui même de supprimer les containers qui ne sont plus utilisés (voir l'option --docker_remove_delay).
[^] # Re: code des drones parrot ?
Posté par Tangi Colin . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 1.
En soft open source pour piloter des drones il y a Openpilot qui a l'air assez sérieux : https://www.openpilot.org/
[^] # Re: un petit résumé de ce qu'est ansible?
Posté par Tangi Colin . En réponse au journal Obtenir un inventaire ansible depuis GLPI. Évalué à 3.
Sur chef ou puppet tu as un client installé sur chaque machine. Ansible c'est du "clientless" ou tout ce fait a travers du ssh.
# Comparer NFS avec un fs implémenté par FUSE faut oser comme meme
Posté par Tangi Colin . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 8.
Parler d'un vrai système de fichier en réseau alors que c'est implémenté en userpace (basé sur FUSE) et dire que ça tiens la comparaison avec NFS faut oser. Niveau perf c'est le jour et la nuit, dès que ta plein de petits fichiers les performances s'écroulent. SSHFS c'est juste pas la bonne architecture (comme tout ce qui est basé sur FUSE), c'est rigolo pour s'amuser mais niveau perf c'est pas bon.
# Gestion de code source (espace de travail) != Gestion des dépendances
Posté par Tangi Colin . En réponse au journal biicode, c'est fini. Évalué à 1.
J'ai toujours trouvé bizarre l'idée d'associer dans un même outil, la gestion des dépendances et la gestion de code source (espace de travail). Ce que je veux dire par la, c'est que pour gérer mon espace de travail qui est composé de plusieurs git, j'utilise un outils dédié (dans mon cas l'outil repo d'android). De plus avec git-lfs ce n'est plus un problème de versionner aussi ses binaires à travers git. Ceci me permet de régénérer n'importe où ma base de code et ceci quelque soit le langage de programmation. Ensuite suivant le langage la partie gestion de dépendance de build et de runtime est géré par le système de build que je choisie.
En C/C++, pour un petit projet, j'aime assez bien la syntaxe android (android.mk).
Pour des projets plus complexes et devant intégrer plusieurs code open-source (qui viennent chacun avec leur système de build), j'utilise le "meta-build-system" yocto mais en prenant soins d'écrire une majorité de mes recettes en utilisant la bbclass "externalsrc" ou avec un git local.
[^] # Re: Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1.
Merci pour le lien vers peru que je ne connaissais pas. Néanmoins il à l'air d'utiliser git submodules, ce dont je ne veux pas. je veux juste un repo avec deux trois options supplémentaire et quand je regarde le code source de repo (python et orienté objet sans aucune doc) bah je me dis que je ferais mieux de partir from scratch avec un script bash pour la "hackabilité" de la chose et le coté zéro dépendance. Après go pourrait être une alternative intéressante aussi.
Quand je trouverai le temps de coder un peu pour moi, gws sera surement un bonne base de départ.
[^] # Re: Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1.
Effectivement je voudrais remplacer repo par gws.
Je vois pas en quoi ces deux projets sont si différents, dans les deux cas on a un fichier qui référence les gits qu'on utilise dans son espace de travail (un manifest), leur emplacement et leur version (fonctionnalité manquant pour gws à l'instant mais pas très compliqué à rajouter).
Le besoin de faire des shallow clones c'est des usages avancés, j'ai des gros git avec beaucoup d'historique et vu gagner sur le temps du git clone.
Changer entre deux version de ton répertoire de travail c'est si tu utilise gws comme repo, passer d'une version à une autre simplement (et en ne présupposant pas qu'entre les deux versions , il a y exactement le meme nombre de git et/ou au même endroit).
# Fonctionnalité manquantes par rapport à android repo
Posté par Tangi Colin . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 3.
Le prochain est intéressant, j'ai l'idée de faire la meme chose qui trotte dans ma tete depuis pas mal de temps a force d'utiliser les manifests repo d'android pour gérer mes workspaces et trouver certaines limitations dans cette outils.
Le choix de faire du bash est vraiment un bon choix je trouve, pour ce genre d'outil je veux avoir le minimun de dépendances. Par contre pour le choix du format de fichier .gws j'aurai utilisé le fichier INI du gitconfig et utilisé git config pour l'analyser.
Y a une fonctionnalité présente dans repo qui manque a gws, c'est le cache local, repo crée un .repo qui va contenir les gits en mode "bare metal", ce qui permet de switcher rapidement entre deux version du workspace sans à devoir tout re-télécharger depuis les serveurs distants.
Deux autres fonctionnalités que j'aimerai voir implémenter (et qui celle la n'est pas dans repo) c'est :
1 la possibilité de choisir ces options de clone/fetch (je veux clonner certains gits en mode bare-metal, d'autre en mode shallow etc…)
2 la possibilité de rajouté un post hook, je vais un gws qui va me générer un workspace, qui va ensuite automatiquement m'appeler un script qui est dans mon workspace. C'est vraiment utile pour versionner des installeur sur lequel on a pas la main.7
En tout cas bravo pour le job. Faudrait que je trouve le temps d'y contribuer un peu.
[^] # Re: Persistence de tout ça
Posté par Tangi Colin . En réponse au journal Vacances & Réseaux hostiles. Évalué à 4.
En un poil plus bourrin tu fais tourner un conteneur docker dans lequel tu as ton VPN et ton appli qui l'utilise.
C'est un peu plus bourrin car tu fera aussi du namespace PID, cgroup en plus du namespace réseau … Mais tu te pausera moins de question puisque c'est l'outil docker qui s'occupera de configurer ton réseau à ta place . Tout dépend de ce que tu veux maîtriser.