C'est mon cadeau de noël à moi : IWLA. Il s'agit, basiquement, d'un clone d'AWSTATS. Pour ceux qui ne connaissent pas, awstats est un analyseur de log (journal des entrées) d'un serveur web (ce dernier faisant aussi l'analyse des logs ftp, ssh, mail...).

C'est un projet qui me tenait à cœur depuis longtemps et, mine de rien, il y a pas mal de boulot juste pour faire des additions !

IWLA a été pensé pour être le plus modulaire possible. Contrairement à awstats qui est complètement monolithique (tout le code dans gros un fichier PERL), l'extraction des statistiques et l'affichage de celles-ci passe par des plugins (hormis les opérations de base). On peut donc ajouter/retirer/modifier à loisir des modules et obtenir exactement ce que l'on veut (et ce de manière très simple). Chaque module va s'occuper de sa partie, voire modifier le résultat des modules précédents !

L'autre avantage (ou inconvénient), est qu'IWLA génère uniquement des pages statiques (en plus de pouvoir les compresser), ce qui accélère la visualisation. Côté design, il reprend le thème d'awstats (ça aurait été beaucoup plus moche si je l'avais fait moi-même) : un design simple qui va à l'essentiel !

Mais ce n'est pas tout, les données (robots, moteurs de recherche), sont directement extraites d'awstats !

Pour finir de troller, IWLA est écrit en Python, ce qui est bien plus moderne :)

Le tout est disponible sous licence GPL sur ma forge. Amusez-vous bien !

Quel drôle de titre ! Je vais donner ici quelques astuces pour éviter que les robots qui parcourent le net n'aient accès à vos données sensibles. Cet article s'adresse surtout aux webmasters.

Qu'est-ce qu'une robot ?

Un robot est un programme automatique qui va scanner tout le web à la recherche d'informations. Tous les robots ne sont pas méchants : Google utilise des robots pour indexer les sites parcourus. D'autres, par contre n'ont qu'un seul objectif : récupérer des informations personnelles pour en faire un mauvais usage (SPAM en tête) ou encore exploiter des failles de sécurité sur les sites rencontrés.

Base64

En tant qu'éditeur de site web (le mien !), je suis aux premières loges. Je n'ai pas envie que mon adresse mail se balade partout sur les annuaires de SPAM, mais je souhaite quand même la fournir aux visiteurs légitimes.

Une astuce que j'ai utilisé et qui fonctionne très bien est d'encoder un contenu que l'on ne souhaite pas exposer aux robots en base64 et de l'inclure dans un div avec comme classe CSS "decode64". Au chargement de la page, un petit bout de Javascript va décoder le contenu et l'afficher. C'est exactement ce qui se passe pour ma page "À propos" (regardez le source). L'inconvénient est l'obligation d'activer le Javascript.

Commentaires

Un système de commentaire sur internet (forum, articles...) est tout aussi sujet à SPAM. Les robots vont écrire automatiquement des commentaires sur tout système qui le leur permet. Pour bloquer cette avarie, on peut soit n'autoriser les commentaires que via inscription (ce que fait Disqus), soit utiliser une petite astuce.

Quand on poste un commentaire, il est souvent requis d'entrer son email. Les robots remplissent donc automatiquement le champ "email" d'un formulaire. Sur Dynastie, j'utilise deux champs email : le premier se nomme "email" et est caché par CSS (donc invisible pour l'utilisateur légitime), et le second "mel" (facultatif chez moi) qui est le véritable email.

Ainsi, quand le moteur de blog reçoit un formulaire dont le champ "email" est rempli, il le rejette, car il ne peut provenir que d'un robot !

Email de contact

Il y a encore une faille dans laquelle s'engouffre les robots spammeurs : l'email de contact. Par convention, on définit souvent une adresse "contact@monnomdedomaine". Les robots peuvent donc tenter d'écrire à cette adresse même s'ils ne l'ont trouvé nulle part (ça ne coûte rien). Le seul moyen pour parer cette attaque est le filtre anti spam du serveur mail...

Direct access to physical address is a bad idea, but sometimes, for debug we need it. The trick used below is to disable MMU for only one instruction that do the read with fully configured environment and then re enabling MMU. Read and enable instructions should be in the pipe. The code works for arm11 but should also works for arm9 and maybe CortexA 32 bits series. Primitives has been found in FreeBSD 10 source code (sys/arm/arm/).

read_arm_phys_addr() must be called in supervisor mode (kernel mode).

#include <stdint.h>

/* CPU control register (CP15 register 1) */
#define CPU_CONTROL_MMU_ENABLE  0x00000001 /* M: MMU/Protection unit enable */
#define CPU_CONTROL_DC_ENABLE   0x00000004 /* C: IDC/DC enable */
#define CPU_CONTROL_WBUF_ENABLE 0x00000008 /* W: Write buffer enable */
#define CPU_CONTROL_BPRD_ENABLE 0x00000800 /* Z: Branch prediction enable */
#define CPU_CONTROL_IC_ENABLE   0x00001000 /* I: IC enable */

uint32_t read_arm_phys_addr(void* addr)
{
    uint32_t value;

    __asm __volatile (
        // Load address                                                                                                                
        "mov     r0, %1\n\r"
        // Disable IRQ, FIQ and abort                                                                                                  
        "cpsid   ifa\n\r"
        // Disable MMU and cache                                                                                                       
        "mrc     p15, 0, r1, c1, c0, 0\n\r"
        "bic     r2, r1, %2\n\r"
        "bic     r2, r2, %3\n\r"
        "bic     r2, r2, %4\n\r"
        "mcr     p15, 0, r2, c1, c0, 0\n\r"
        "nop\n\r"
        "nop\n\r"
        "nop\n\r"
        // Read data                                                                                                                   
        "ldr     r3, [r0]\n\r"
        // Enable MMU                                                                                                                  
        "mcr     p15, 0, r1, c1, c0, 0\n\r"
        "nop\n\r"
        "nop\n\r"
        "nop\n\r"
        // Enable IRQ, FIQ and abort                                                                                                   
        "cpsie   ifa\n\r"
        "mov     %0, r3\n\r"
        : "=r" (value)
        : "r" (addr), "i" (CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_DC_ENABLE | CPU_CONTROL_WBUF_ENABLE),
        "i" (CPU_CONTROL_IC_ENABLE), "i" (CPU_CONTROL_BPRD_ENABLE)
        : "r0", "r1", "r2", "r3");

    return value;
}

Il n'y aura pas de 9e édition des JM2L. Un manque de volontaires pour l'organisation est à l'origine du problème. C'est fort dommage, car cet événement est très sympathique.

Majoritairement organisé par les élèves de l'école d'ingénieur Polytech Nice-Sophia, on peut se demander où est passé l'esprit du libre. Peut-être a-t-il décidé de rester cloîtré dans le pseudo Éden propriétaire...

Ça y est, je viens de contribuer à Linux ! Je ne parle pas du système d'exploitation GNU/Linux, que l'on raccourci souvent en "Linux" chez le grand public (la confusion est volontaire), mais bel et bien du noyau Linux, à savoir la partie qui gère directement le matériel (pour l'exporter aux logiciels sus-jacent). Comme vous le savez, il n'y a pas que les barbus intégristes vivant dans une cave qui ont un noyau Linux, mais bel et bien 95% des utilisateurs de smartphones (grâce à Android). On peut aussi rajouter plus de 90% des supercalculateurs, une bonne 20% des serveurs et quelques pourcent chez les utilisateurs finaux.

Le bug

Le bug corrigé (car oui, c'était un bug), fait partie du sous-système mmc (MultiMediaCard). Il s'agit d'une mémoire de stockage contenue dans les cartes SD, mais aussi intégrée dans la plupart des systèmes embarqués tels que les téléphones. Bref, il est possible de partitionner une mmc physiquement (sans possibilité de retour arrière). Cette opération se fait en deux temps : écriture des paramètres et finalisation (bit EXT _ CSD _ PARTITION _ SETTING _ COMPLETED). Le noyau précédent ne vérifiait pas la finalisation et utilisait les données de partitionnement si elles étaient présentes (ce qui engendre des erreurs par la suite).

Pourquoi ce problème est-il passé à la trappe ? Parce que la plupart des mémoires sortent d'usine déjà partitionnées. Pour le reproduire, il faut avoir une mmc vierge et faire l'opération manuellement.

Développement Linux

Les choses commencent à devenir drôle à partir de maintenant. La communauté qui développe le noyau est composée de développeurs, de mainteneurs et d'UN intégrateur. Vu le travail monstre qui est réalisé, l'intégrateur à savoir Linus Torvald en personne (l'initiateur du projet) doit faire confiance à des mainteneurs pour chaque sous-système du noyau. Ces mainteneurs sont chargés de récolter les modifications (patchs) des développeurs et participent éventuellement eux-mêmes à ces modifications. La plupart travaillent pour une entreprise ou sont rémunérés par une fondation.

Autant le dire tout de suite : le niveau technique de toutes ces personnes est très important. En plus de cela, il faut respecter scrupuleusement les normes de codage du dictateur sous peine de se faire jeter lamentablement. Pour ma part, j'ai eu affaire à Ulf Hansson (un des mainteneurs du sous-système mmc) qui travaille pour la fondation Linaro. Ce qui est drôle c'est que, suite aux échanges, je suis passé d'une simple modification (~ 17 lignes) à une série de trois patchs (~ 176 lignes) + une lettre de couverture (cover letter) expliquant en détail la nature du patch. Il m'a fallu pas moins de 6 versions sur deux mois (principalement des questions de forme) pour arriver à un résultat parfait, ce qui peut être vraiment décourageant.

Déroulement des opérations :

• Mardi 17 juillet 2014 : Permière version envoyée sur la liste
• Mercredi 13 août 2014 : Réponse d'Ulf
• Lundi 18 août 2014 : Après quelques discussions, soumission de la deuxième version (améliorée)
• Lundi 18 août 2014 : Réponse d'Ulf, Les patchs ont le même entête et il manque l'historique.
• Lundi 18 août 2014 : Soumission de la troisième version
• Lundi 8 septembre 2014 : Réponse d'Ulf : c'est cool, mais le patch bouge du code ET fixe un bug en même temps
• Jeudi 11 septembre 2014 : Soumission de la quatrième version, trois patchs
• Jeudi 11 septembre 2014 : Réponse d'Ulf, le second patch ne compile pas. Il faudrait être plus clair dans les explications et il y a des accolades inutiles
• Vendredi 12 septembre 2014 : Soumission de la cinquième version avec une lettre de couverture contenant tous les détails du patchset
• Lundi 15 septembre 2014 : Réponse de Jaehoon Chung : j'ai oublié de supprimer les accolades
• Lundi 15 septembre 2014 : Soumission de la sixième version
• Jeudi 18 septembre 2014 : Acception du patch par Ulf

Que ce fut long ! Deux mois pour pousser un patch. Pour autant, ce n'est pas fini. Le patch a été intégré dans la branche 'next' d'Ulf. Celle-ci sera intégrée le lendemain dans la branche next du noyau qui servira de base pour la prochaine version (3.18).

Outils

Il y a plusieurs façons de générer un patch. Au début, je n'avais pas envie de récupérer les gigas octets que représentent le git du noyau, donc c'était à la main à partir d'un tar. On se rend vite compte que pour un patch un peu plus évolué sur un noyau qui bouge tout le temps, il faut absolument passer par git et ses commandes magiques : git-format-patch/git-apply/git-am. En plus d'être efficaces, elles ont été conçues pour ça (et ne parlons pas de la possibilité de créer des branches de développement pour tester/valider ses patchs). Il faut juste avoir le courage de faire le clone initial...

Conclusion

Envoyer un patch pour la première fois relève du parcours du combattant ! La modification est maintenant intégrée dans le noyau 3.18 (sortie définitive décembre 2014). Mes quelques lignes de code seront donc exécutées au démarrage des prochains smartphones équipés d'un noyau d'une version égale ou supérieure à 3.18. Donc, si ça plante, ce sera peut-être un peu de ma faute :)