Hardening consulting

J'écoute pas mal de musique en codant et je trouve que ça associe un souvenir au travail qu'on fait. Souvent quand je ré-entend des morceaux que je n'ai pas écouté depuis longtemps, le souvenir du code sur lequel je travaillais à cette époque remonte toute de suite. Par exemple, l'album climax d'Alain Bashung m'évoque tout suite le voiceXml.

Et donc en ce moment, j'écoute des groupes d'origine rennaise qui font de l'electro, on verra ce que ça m'évoque d'ici quelques temps:

Juvéniles

Manceau

O-safari

Cette conférence a lieu chaque année et je trouve que les interventions sont techniquement intéressantes. Les matériaux (slides et sans doute bientôt les vidéos) sont disponibles depuis cette semaine. Parmi toutes ces conférences, celles qui ont particulièrement retenues mon attention:

  • Les chiffres de Linux Transparent Memory Compression sont assez impressionnants: en ajoutant une étape qui compresse la mémoire avant d'envisager de l'envoyer au swap, on pourrait fonctionner sans dégradations importantes à 140% de la mémoire !
  • La conférence Writing Code: Keep It Short, Stupid!, on dirait une liste des conseils que j'applique pour le code. Ça fait bizarre de s'entendre dans les slides de quelqu'un d'autre.
  • Binary compatibility for library developers donne des directives pour assurer une compatibilité binaire d'une librairie (respect de l'ABI). Intéressant et méconnu, même si on peut pressentir les actions qui poseront problèmes.

Le site des tous les slides est ici.

Quand un client fait une mise à jour de l'affichage, la nouvelle image pourrait être envoyé à travers la socket entre le client et le compositor, mais ce serait extrêmement lent: des appels à read() / write() passant par la case kernel sans parler des coûts de copie mémoire associés.

Dans wayland, il a été choisi de partager ces informations de surfaces en utilisant des mémoires partagées. Le design est le même que l'extension SHM de X11, sauf que dans wayland ce n'est pas une extension mais le seul moyen pour envoyer des surfaces au compositor.

Petite note: une des différences entre mir et wayland, c'est que les buffers sont gérés par le serveur dans un cas et par les clients dans l'autre.

Donc tout roule comme sur des roulettes, le client fait ses mises à jour de l'affichage dans la zone de mémoire partagée, et il prévient le compositor en envoyant des ordres de mises à jours dans la socket qui le relie au compositor.

Problème: si on se contente de ça, on va avoir des accès concurrents sur le buffer partagé: le client et le serveur vivent leur vie chacun de leur coté, et il y a fort à parier que le client va vouloir faire d'autres modifications graphiques pendant que le serveur sera en train de fabriquer l'image globale du desktop. Pour régler ce problème, le client est prié de ne plus utiliser le buffer tant que le serveur ne l'aura pas notifié. Le serveur notifie les clients quand il a utilisé un buffer pour faire la mise à jour de l'affichage, ce qui permet au client de libérer ou de réutiliser ce buffer.

double-buffering Le client ne va pas rester à se tourner les pouces en attendant que le serveur ai fini ses opération, on a une implémentation assez classique de double-buffering:

  • le client alloue 2 buffers;
  • il dessine dans le premier;
  • il notifie le compositor de la mise à jour de la surface;
  • il dessine dans le second;

Entre temps le compositor devrait avoir notifié de la libération du premier, ce qui permettra de s'en resservir.

triple-bufferingOn peut aussi faire une implémentations de triple-buffering:

  1. un buffer envoyé au compositor;
  2. un buffer qu'on a préparé et qu'on attend d'envoyer;
  3. un buffer qui sert pour les modifications courantes

Quand on recevra un avis de libération du buffer 1, on shifte les buffers:

  • le buffer 2 est envoyé;
  • le buffer 3 devient celui qui est en attente d'envoi;
  • et le buffer 1 qui vient d'être libéré devient celui qui sert pour les modifications courantes

Wayland ne fige pas comment est implémenté tout ceci, il ne fourni qu'un service de pool de buffer, le client l'utilise comme il lui semble le plus efficace ("wayland is all about choices").

Sources

Les éléments cités dans cet article:

  • le fichier qui décrit le protocole wayland avec la partie wl_shm. Le code de parsing est généré à partir de ce fichier;
  • l'article de wikipedia sur le multiple-buffering, d'où sont extrait les schémas.

wayland Un billet touffu pour parler du compositeur RDP dans weston, le compositeur de référence de wayland.

Présentation wayland / weston

Le projet wayland vise à remplacer X11, il ne défini qu'un protocole. Il se concentre sur ce que X11 aurait dû rester: une manière de faire des IPCs (Inter Process Communication).

Tiré de la documentation du projet wayland, quand un client fait des mises à jour de son affichage sous X11:

Architecture avec X11

On voit qu'avant que les actions des clients du server X atteignent le matériel, on a tout le temps de voir du paysage:

  • le client envoie ses actions au serveur X ;
  • il les envoie au compositeur (le gestionnaire de fenêtres la plupart du temps), qui renvoie au serveur X l'image à afficher ;
  • et finalement ça atteint le matériel, ouf !

    Lire la suite…

waylandJe travaille par intermittence sur un patch dans weston (le compositeur de référence pour wayland) pour que les changements de résolution fonctionnent correctement et surtout que les clients soient prévenus quand un changement de mode (résolution, fréquence de rafraîchissement) intervient.

J'en ai discuté longuement sur IRC, proposé plusieurs morceaux de code et finalement c'est intégré: ça devrait finir dans la version 1.3. Ça fait plaisir quand des petits bouts de réflexion et de travail étalés sur un mois sont finalisés.

Les commits:

  • le premier pour faire des renommages
  • le second pour faire le boulot

Du coup, maintenant quand on se présente avec un client RDP sur le compositor RDP, que la résolution du desktop ne correspond pas à celle du client, c'est le desktop qui change de résolution et plus le client comme c'était le cas dans l'implémentation précédente.

qt5

Alors les plus grognons me diront:

mais c'est quoi ton platform integration bidule là....

Alors un platform integration plugin, c'est le plugin qui permet de s'occuper d'une partie de du matériel sous Qt, ça permet entre autre de gérer la partie graphique (xcb, x11, wayland) ou encore les méthodes d'entrée (heu là joker pour cette partie).

Donc on a fait notre magnifique code de platform integration plugin, ça ressemble à ça:

class QFreeRdpIntegration : public QPlatformIntegration
{
public:
    QFreeRdpIntegration(const QStringList &paramList);
    ~QFreeRdpIntegration();
/** bla bla bla reste de la class */

};

On peut s'en servir avec une application en faisant un savant:

# mon_application -platform <nom de mon plugin>

C'est super. En regardant de plus près, on se dit que paramList serait vraiment très appétissant, pour passer des paramètres au plugin (vu le nom). Seulement voilà, la doc est plutôt muette à son sujet. On sait que c'est la liste des paramètres par contre pour savoir comment les passer à l'application.... Mystère !

Après une bonne heure de recherche sur internet sur d'obscures mailing list Qt4 mobile (oui oui Qt4), je trouve l'incantation qui permet de lancer le sort:

# monapplication -platform <nom de mon plugin>:param1:param2

Et on récupère param1, param2 dans le tableau paramList, c'est magique.

Elle est pas belle la vie ?

échec du calibrage

J'avais changé la cartouche d'encre noir récemment donc elle avait de l'encre.

Ce soir j'ai donc décidé de m'attaquer à la bête, 20 pages de calibrages plus tard, plusieurs heures de recherche dans les forums, les mains dégueux à laver les têtes d'impression, et la lumière vient à moi:

plus d'encre de couleur ! La page de calibrage était en noir et blanc + couleurs et pas seulement en noir et blanc.

Messieurs de chez HP, je vous maudis jusqu'à la cinquième génération de n'avoir rien écrit à ce propos sur cette fucking page de calibrage.

Mettre wordpress, ça m'inspire un peu de laisser sa porte d'entrée ouverte et de mettre devant la maison un panneau publicitaire de 4 mètre sur 3:

venez, c'est ouvert !

En butinant sur le web, j'ai trouvé quelques liens intéressants pour sécuriser wordpress, notamment:

  • une page donnant ce que j'appellerais des pratiques évidentes (on dirait le manuel d'hygiène du SI de l'ANSSI ;) )
  • un plugin faisant firewall pour wordpress

Hope it helps.