Meltdown and Spectre: the juiciest bug of 2018?

2018 starts wonderfully: a new kind of vulnerability has been disclosed, an hardware bug!

Documentation about this is available from sources with considerable authority, from university researcher or google official blog.

However, a closer analysis of the threats raises doubts about their seriousness. The risk to be affected by them seems rather low.

“...Meltdown allows an adversary who can run code on the vulnerable processor…” [https://meltdownattack.com/meltdown.pdf]. Thus for dedicated server, the vulnerability implies a logged attacker. Of course for VM or VPS, you don’t control who runs code on the physical host you share. But servers administrator core preoccupation is to keep attacker from logging on their systems.

As for “Spectre” [https://spectreattack.com/spectre.pdf], the so called proof of vulnerability – among other prerequisites unlikely to happen – relies on the “victim” code to have an instruction such as “if (x < array1_size) y = array2[array1[x] * 256];“! Who would write such a code and what for?

These two quoted papers remind of academic context where such unpractical conditions hidden behind well handled complexity are often observed. The underlying techniques are too complex to be easily understood but the presentation is convincing.

Even google (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) admits that “To take advantage of this vulnerability, an attacker first must be able to run malicious code on the targeted system.

Anyway, even if the risk is much lower that it is presented, the inevitable result will be a massive update frenzy: an ideal opportunity to deploy other vulnerabilities, spywares or backdoors and to motive hardware replacement…

First, the software fix will decrease performance: a motivation to invest in faster – and more expensive – systems. Eventually the hardware fix will require new computers. Thus it is not surprising that all CPU vendors happily admit that their products are affected.

Whatever dangerous Meltdown and Spectre may be, they are certainly a huge opportunity of profit.

Well done.

 

L’EURL Barme change de nom commercial…

… et s’appelle désormais numerunique :

En fait une société a trois identifiants :

  1. sa dénomination ou raison sociale,
  2. son nom commercial,
  3. son enseigne commerciale.

Ce nouveau nom commercial reflète davantage l’activité de numerunique. C’est la contraction de numérique et unique et justement, lorsque on fait le bilan de son activité depuis bientôt 10 ans, numerunique fourni des services numériques si personnalisés qu’il sont en fait uniques.

Ce changement – dans la continuité, car c’est toujours la même entité et elle conserve sa raison sociale – est renforcé par un nouveau logo, produit par numerunique.art, plus conforme lui aussi à l’activité de numerunique :

A gauche le 0 symbolise le numérique, à droite, le 1 symbolise l’unique et, au centre, les deux fusionnent dans un objet binaire en 3 dimensions qui symbolise la concrétisation des services numériques uniques de numerunique.

Comparaison de quelques types d’accès à Internet

Quelques tests de différents type d’accès à Internet donnent :

Type d’accès IP Réception max Envoi max Latence min gigue
Wi-Fi distant fixe 0.241 0.657 0.36 0.514 186.1 39 1060
Ethernet via CPL fixe 5.523 5.758 0.708 0.788 42.17 39.8 7.4
Wi-Fi Orange 3G variable 8.194 11.28 0.417 0.542 268.2 91.58 332.3
Wi-Fi proche fixe 11.89 12.28 0.791 0.84 80.91 38.91 171.2
Ethernet direct fixe 11.95 12.12 0.639 0.708 41.05 37.54 8.39
Wi-Fi Free 4G variable 70.87 77.5 7.28 8.988 129.5 54.17 158.2

Les débits de réception et d’envoi sont en Mb/s, la latence et la gigue en ms.

Pour la meilleure réception :

  1. Wi-Fi Free 4G
  2. Ethernet direct
  3. Wi-Fi proche
  4. Wi-Fi Orange 3G
  5. Ethernet via CPL
  6. Wi-Fi distant

Pour l’envoi le plus rapide :

  1. Wi-Fi Free 4G
  2. Wi-Fi proche
  3. Ethernet via CPL
  4. Ethernet direct
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Pour la meilleure réactivité :

  1. Ethernet direct
  2. Ethernet via CPL
  3. Wi-Fi proche
  4. Wi-Fi Free 4G
  5. Wi-Fi distant
  6. Wi-Fi Orange 3G

Pour la meilleure stabilité :

  1. Ethernet via CPL
  2. Ethernet direct
  3. Wi-Fi Free 4G
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Synthèse (tous critères) :

  1. Ethernet direct
  2. Wi-Fi Free 4G
  3. Ethernet via CPL
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

En bref :

  • La 4G est vraiment rapide à défaut d’être stable.
  • L’Ethernet direct et le wifi proche se valent.
  • Le pire est le Wi-Fi trop distant.

Ces conclusions sont juste indicatives : en pratique, les résultats des tests sont spécifiques à un lieu et un moment donnés.

Le plus petit SaaS ?

C’est “L’adpresse IP publique” : lip.ovh !

A voir tous les sites qui propose de vous révéler votre adresse IP publique, c’est un service très demandé. Mais lip.ovh se distingue de ses analogues à plus d’un titre :

  1. son nom est le plus court
  2. c’est le service le plus concis,
  3. il n’a aucune pub,
  4. c’est le moins cher.

On accède à lip.ovh en 7 caractères seulement ; on pourrait faire plus court sur un TLD de 2 lettres qui accepte des noms de domaine à moins de 3 lettres mais se serait plus cher.

Ce SaaS (Software as a Service) affiche uniquement l’adresse IP publique de celui qui l’utilise, et rien d’autre. Difficile d’en faire moins.

lip.ovh est hébergé sur un hébergement mutualisé gratuit ; son prix de revient est donc de 0.0825 € HT par mois. Qui dit mieux ?

A ce prix là, ce service est royalement offert par l’EURL Barme qui en profite pour illustrer l’approche minimaliste et économique qu’elle propose à ses clients.

L’EURL Barme entame sont 10ème exercice

Depuis le 1er juin 2017 l’EURL Barme est entrée dans sa 10ème année. Et 10 est un chiffre exceptionnel qu’il est courant de célébrer. C’est encore plus opportun pour un informaticien.

Un informaticien jongle forcément avec les bases binaire, décimale et hexadécimale. La base 2 est celle des ordinateurs et des circuits logiques. Elle utilise 2 chiffres, le 0 et le 1. 10, qui vaut 2 en binaire est donc un nombre particulier à plus d’un titre puisque les bases binaires et décimales y convergent.

A cette occasion, l’EURL Barme lance une nouvelle activité :
numerunique.art.

Au premier abord c’est une activité dont le modèle économique cumule les handicaps : les charges considérables de conception et l’absence d’économie d’échelle qu’apporte la production en masse.

Pourtant, c’est justement ce qui est au cœur de l’activité principale de l’EURL Barme : l’application de l’outil informatique pour un usage spécifique. C’est donc une niche à l’écart de laquelle se tiennent les sociétés dont l’objectif exclusif est la rentabilité mais c’est l’écosystème dans lequel l’EURL Barme d’épanoui depuis bientôt 10 ans, pour la plus grande satisfactions de ses clients.

Consommation électrique

A l’instar du système mis en œuvre pour visualiser la consommation d’eau, l’installation d’un capteur équivalent permet d’accéder à celle de l’électricité.

capteur_elec

Amélioration du tableau électrique

Légende :

  1. le capteur de consommation électrique avec une sortie numérique,
  2. la sortie numérique du capteur reliée au Raspberry Pi (tout comme pour le capteur de consommation d’eau),
  3. une alimentation 5V DC 2.4A,
  4. le branchement de l’alimentation sur le Raspberry Pi.

Attention, si en théorie l’ajout du capteur au tableau électrique est simple, en pratique il est nécessaire de la confier à un professionnel.

L’ajout d’une alimentation installée sur le rail DIN est optionnel mais tant qu’à faire déplacer un électricien pour l’installation du capteur de consommation électrique, autant en profiter !

Le captage des impulsions est identique à celui fait pour l’eau. La conversion en watt est différente et dépend (un peu) du capteur mais l’affichage est similaire :

ConsommationElectrique

La consommation instantanée

C’est vraiment pédagogique de voir sa consommation d’énergie en temps réel ! En vidéo, c’est plus démonstratif : https://youtu.be/WDUL1vy2zWc

Il ne reste plus qu’à exploiter l’information pour faire des économies et contribuer à lutter contre le réchauffement climatique.

Pour l’exemple du café de la vidéo, on a consommé environ 10 W/h pour faire le café, soit 1 cent TTC pour l’électricité. Il faudrait estimer les coûts d’eau et de grains de café pour avoir un prix de revient mais on peut raisonnablement penser que ce n’est pas en limitant le nombre d’expresso que l’on sauvera la planète. Ouf !

La spirale infernale des mises à jour

C’est désormais bien entré dans les mœurs : les matériels, systèmes et logiciels doivent être régulièrement mis à jour. Au point qu’il est fréquent d’entendre que tel ou tel logiciel ne vaut plus rien puisqu’il n’est plus mis à jour ! Ce genre de principe érigé en dogme est le plus souvent colporté par ceux qui cherchent désespérément à palier leur incompétence par des règles faciles à comprendre.

Le problème avec les mises à jour est qu’elles sont la plupart du temps (mais pas toujours) inutiles voire préjudiciables : certaines apportent davantage de bugs ou de failles de sécurité qu’elles n’en corrigent.

Le plus pénible avec les mises à jour de système d’exploitation est qu’elle impliquent en général la nécessité d’un changement d’ordinateur. Le plus horripilant est d’avoir à redécouvrir le nouvel accès à une commande, un service ou une fonctionnalité par ailleurs identique ou même dégradée…

Et si un programme qui n’est plus mis à jour était tout simplement arrivé à maturité ?

C’est encore pire pour les équipements.

Acheté il y a 2526 jours à la date ce cette photo, ce téléphone (un HTC desire 2010) suppliait d’être remplacé.
HTCdesire

Aujourd’hui on a un choix incroyablement riche pour un téléphone :

  1. Android
  2. iOS

Dans le premier cas, on confie toutes ses données personnelles à google, dans le second à Apple. Et en plus, on paye (cher) pour le faire, c’est quand même génial tout ça.

En l’occurrence, c’est le choix 2 qui a été fait. Il en résulte un problème intéressant pour un informaticien : transférer 419 contacts d’un téléphone Android vers un iPhone.

Pour pimenter un peu la chose, on veut éviter de passer par iCloud. A priori il n’y a rien d’ultra secret dans ces contacts mais c’est une question de principe, alors si c’est une question de principe…

L’extraction des contacts depuis un Android de 2010 est simple, en quelques touch on a un .vcf standard sur la carte SD que l’on peut même récupérer par Bluetooth.

L’import sur l’iPhone se présente moins bien : le modèle choisi n’est pas “résistant aux éclaboussures et à l’eau” mais il est parfaitement étanche à toute forme d’échanges de données, quel qu’elles soient, sauf à passer par iCloud ou iTunes, bien sûr.

Va pour iTunes, officiellement cela reste local. D’ailleurs, il faut même utiliser une connexion par câble pour une synchronisation avec iTunes. Les fonctionnalité Bluetooth supportées entre un Mac et un iPhone sont très économes… seule une connexion réseau est possible. Quelle valeur ajoutée !

Hélas, le MacBook air du propriétaire du vieux HTC et du nouvel iPhone réclame une mise à jour d’iTune en préalable à toute tentative de synchronisation. iTune étant à jour, il faudrait commencer par faire une mise à jour du MacOS. L’opération est risquée, le MacBook air en question est d’une autre époque (i.e. vieux de quelques années).

Alors on passe par un autre mac plus récent, sur lequel on crée un compte temporaire. Il faut quand même y faire une mise à jour d’iTunes. Et là ? On découvre que la synchronisation des contacts ne peut se faire désormais que par iCloud :-((

Moralité, lorsqu’on change de téléphone, il faut aussi changer d’ordinateur. Ils devraient proposer un lot.

Heureusement, il y a un moyen de contourner le blocage : un simple mail (d’une messagerie étrangère à Apple ou google) avec le .vcf en pièce jointe et hop, on récupère ces 419 contacts sur l’iPhone, sans passer par iCloud, comme promis.

PS : c’est impressionnant comme la touche i s’use plus vite lorsqu’on parle de Mac.

Comment perdre 2 ans de confiance en 2 heures

Les faits

08:44

Un client de l’EURL Barme signale l’indisponibilité d’un service.

08:55 Création d’un ticket incident :

Bonjour,

Que ce soit depuis l’extérieur (ping barme.fr 195.154.60.32) ou par le RPN (ping 10.x.x.x), le serveur ne répond pas.

Est-ce un problème réseau ?

Merci.

08:58 réponse du support :

Bonjour,

Je fais quelque vérifications et reviens vers vous dans les plus brefs délais.

Cordialement,

09:01 (support) :

Bonjour,

Je vois des logs sur le kvm qui peuvent indiquer une Kernel Panic.

M’autorisez-vous à passer le serveur en mode secours afin de faire quelques tests? Je reviendrai vers vous dès les tests finis.

Cordialement,

09:08 (EURL Barme) :

Oui, passez en mode rescue.

A noter, j’ai basculé mon IP failover sur mon serveur de secours.

09:36 (support) :

Bonjour,

Après les tests que j’ai effectué, il apparaît que le serveur est fonctionnel et n’a pas de souci matériel.

Je vous invite à regarder du côté Software/OS et installation ou configuration.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:40 (EURL Barme) :

ping x.x.x.x: 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C

Vous appelez ça fonctionnel ?

09:43 (support) :

Bonjour,

J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:45 (EURL Barme) :

Merci, je sais ce que c’est le mode secours.

Ne touchez donc plus à rien ; je vais investiguer par moi-même.

09:47 (EURL Barme) :

A noter le “Monitoring” :

Monitoring

Service Statut

Ping du serveur Disponible il y a 1 année historique

!!

09:54 (support) :

Bonjour,

Très bien.

Cordialement,

10:00 (EURL Barme) :

Mon serveur sd-x est à nouveau opérationnel, directement sans _aucune_ modification de sa configuration…

Un simple reboot aura donc suffit à le remettre en service ; c’est habituel de mettre en cause la configuration du client mais comment pouvez-vous le justifier ?

10:16 (support) :

Bonjour,

Je vois que le souci sur ce serveur est résolu après un simple reboot.

Je vous invite à clore le ticket et à le noter en laissant un commentaire.

Bonne journée,

10:20 (EURL Barme) :

Dans syslog, j’ai :

Apr 11 21:17:01 ol1 /USR/SBIN/CRON[46128]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
Apr 12 09:40:42 ol1 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Donc mon serveur est down depuis hier 21:17:01 et à nouveau opérationnel depuis 09:40:42 ce matin.

Et pourtant votre monitoring ne m’a pas alerté et prétend qu’il est disponible depuis 30/09/2015 09:52:18 ! ?

N’y aurait-il pas un problème de votre coté ?

10:44 (support) :

Bonjour,

Je transmet votre demande au service concerné et nous reviendrons vers vous dans les plus brefs délais.

Cordialement,

10:53 (EURL Barme) :

Cela vous amuse de passez mon serveur en mode rescue sans prévenir ?

11:03 (EURL Barme) :

Vos techniciens mettent mon site HS alors que je leur ai demandé de ne plus y toucher à 12/04/2017 09:45:53.

C’est pourtant pas un jouet ce serveur !

11:09 (support) :

J’ai prévenu mes collègues en charge

— —

Cordialement,

11:30 (support) :

Bonjour,

je reprends la suite du ticket au vu du signalement de celui-ci.

Un quiproquo et un échange trop rapide lors de la remonté a en effet entraîné un autre passage en secours.

Je confirme que le serveur est bien opérationnel de mon côté

Il ping bien en mode normal.

J’ai remis à jour le monitoring sur le serveur en espérant que vous soyez allertez la prochaine fois.

Rien ne vous empêche de mettre en place votre propre monitoring.

Cordialement – Technicien Premium

Commentaires

C’est toujours dans un contexte défavorable qu’un incident survient, en l’occurrence lors d’un déplacement, avec un contexte technique d’intervention et une disponibilité réduits.

Evidemment, c’est un client qui découvre et indique le problème ; en temps normal il aurait été découvert bien plus tôt et l’investigation de l’EURL Barme aurait été faite directement par une connexion sur la console du serveur, avant de faire intervenir le support.

Le support a été très réactif : réponse au ticket en 3 minutes. Son diagnostique initial (Kernel Panic) a été confirmé par le technicien Premium intervenu après escalade du problème.

Erreur du support : retour sans vérifier que le serveur est opérationnel après sortie du mode rescue. Il aurait été préférable d’attendre la fin du redémarrage.

Dérapage du support : mise en cause arbitraire du client (“J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.”)

C’est un grand classique de tous les supports de mettre systématiquement le client en cause. C’est évident que la plupart des remontées faites aux supports le sont par des personnes aux compétences informatiques modestes et de surcroît sans doute agressives car le problème pour lequel elles appellent est mal vécu. Mais ce n’est pas une raison pour mettre tout le monde dans le même panier et considérer, a priori, que l’origine du problème est du coté du client. La bonne approche devrait être de vérifier en premier s’il n’y a pas un souci du coté du prestataire et rien n’empêche, ensuite, de mettre le client face à ses responsabilités.

Erreur gravissime du support : passer un serveur de production (qui fonctionne !) en mode rescue sans autorisation du client. Là c’est le summum de l’inconséquence et totalement inadmissible de la part d’un service professionnel.

Ensuite c’est l’escalade et le problème atterri sur le dos d’un technicien “Premium” qui n’y est pour rien et ne peut plus rien y faire. Le terme “Premium” fait sourire avec sa connotation de “compétence supérieure”. Techniquement c’est sans doute vrai mais dans le contexte, ce sont davantage des compétences en communication qui sont requises.

Ce technicien “Premium” prendra la peine d’appeler pour signaler le retour au mode normal du serveur, ce qui est très bien et courageux de sa part mais son ton condescendant face à un interlocuteur avec 36 années d’expériences en informatique dans un tel contexte sera la cerise sur le gâteaux… Une formation de base à la communication lui serait bien utile.

Et pour la suite…

Les serveurs sous linux sont très fiables mais pas infaillibles. C’est justement la raison pour laquelle un serveur dédié utilisé pour un service critique  ou non doit être doublé par un clone synchronisé automatiquement et en permanence avec le serveur en fonction. Un kernel panic isolé est un aléa potentiel qui ne remet pas en cause le serveur ni sa configuration.

De même un incident isolé mal géré ne remet pas en cause un prestataire ni son professionnalisme.

L’EURL Barme ne changera donc pas ses serveurs impliqués dans cet incident et ne souhaite finalement qu’une chose : que cesse cette habitude des supports de mettre systématiquement en cause le client.

Epilogue

A l’occasion d’un autre souci technique (mineur celui-là) sur mes serveurs chez Online, j’ai eu affaire à un service de qualité, tant en compétences techniques qu’en communication.
Comme quoi cela dépend beaucoup des interlocuteurs ; il y en a des décevant mais aussi des très bons.
Ouf, mes serveurs sont décidément bien gérés et mes fournisseurs bien choisis 🙂

Why frameworks suck?

ol1

OPEN LOOK, once it was a must, now it’s but a mug – a nice and dear one though.

ol2

This is just an example of a wonderful framework: in 1990, it allowed building homogeneous UX for applications on top-of-the-moment desktop workstations.

As all really powerful frameworks, it required a long and tedious learning time – often with a steep initial learning curve – but with a beautiful result. The problem is that all the knowledge acquired to master it is now lost and this is the fate that doom all frameworks, thousands of framework since 1990.

The core of the problem is that frameworks provide high-level functionalities that don’t last more than the underlying fashion. As a programmer, one should look after learning how to build complex tools with low-level instructions: that will last forever.

Of course it is worst to reinvent the wheel; except for very special cases, nowadays nothing useful can be achieved with machine language. Using a higher-level language – whatever – is better. And while working within a team, frameworks provide a strong common context.

So yes, frameworks are useful somehow. But then use them scarcely, staying aware that you will soon need to forget all about them and learn the next one.

Beside, there is another drawback to the use of frameworks: they constrain what you can do with them. If your specifications is close to what a framework is meant for, you will probably benefit of its use. If not, then the challenge to adapt the framework to your need is so expensive that you end in adapting your specification to what the framework allows.

Framework are definitely incompatible with specific developments.

Comptage d’impulsion – vue d’ensemble

Que ce soit pour la visualisation de la consommation d’eau en temps réel ou celle de la puissance électrique instantanée, le principe de base est le même :

archi

  1. Il y a d’abord un capteur qui fournit l’information recherchée sous forme d’impulsions électroniques.
  2. Un processus activé par interruption logicielle relève ces impulsions aussi vite que possible.
  3. Un autre processus stock tranquillement ces relevés d’impulsion dans une base de données.
  4. Un serveur web anime un mini site internet qui récupère les données et les transforme en informations présentées dans un navigateur.

Les impulsions sont fugitives ; il est important de ne pas les rater et de pouvoir mémoriser l’instant de leur occurrence aussi précisément que possible.

Naturellement, comme dans l’exemple indiquée dans un commentaire sur l’exemple de code pour l’étape 2, une solution simpliste consiste à enregistrer dans un fichier le nombre total d’impulsions comptées et la date et l’ heure de la dernière impulsion.

Cependant, c’est long, relativement à la brièveté d’une impulsion. Il faut en effet : ouvrir le fichier, lire la dernière valeur du compteur, recréer une nouvelle version du fichier avec la nouvelle valeur du compteur et la date et l’heure de la dernière impulsion. Si les impulsions sont trop rapprochées, on pourrait en rater. Par ailleurs, un décalage, d’une valeur plus ou moins aléatoire, s’introduit entre l’impulsion qui déclenche le traitement et le moment où l’heure est relevée.

En plus c’est pauvre : on ne conserve que le nombre total d’impulsions et la date de la dernière occurrence.

C’est pour cela qu’il est préférable de faire le traitement des impulsions en deux étapes : une lecture aussi rapide que possible (étape 2) puis, indépendamment et  sans contrainte de temps d’exécution, le stockage de chaque impulsion dans une base de données (étape 3). Ce traitement est fait à l’initiative de l’étape 4 et, en parallèle, il est aussi fait à intervalles réguliers. Ce qui permet d’avoir l’information la plus récente possible à afficher et éviter qu’un trop grand nombre d’impulsions ne s’accumulent avant d’être stockées en base de données si l’affichage n’est pas sollicité suffisamment souvent.

De plus, le stockage de toutes les impulsions dans une base de données ouvre la voie à de nombreux traitements et analyses.