Informatique - Page 33

Oldies : Benchmark vieux HDD Conner du 486

31/03/2017 | Informatique | 1 Commentaire

Suite aux commentaires de Deksor concernant mon 486, j'ai passé deux disques durs IDE en bench.
Voici les résultats entre le Conner d'origine (240Mo) et un autre Seagate plus récent (850Mo) que j'ai sous la main.

	PC 486 (Winbond W83757F)	PC Pentium MMX (Intel 82371SB)
Conner CP30254
Seagate ST3850A

Que peut-on en conclure ?

Spécifications : Hormis la capacité qui diffère, déjà que le Conner ne possède que 32Ko de cache par rapport au Seagate qui lui en possède 120Ko. De plus le Seagate est en mode PIO4 et gère le DMA 2(0) alors que le Conner est limité au mode PIO3.

Temps d'accès : Le Conner passe les tests avec un graphe en forme de "deux montagnes" : première fois que je vois cela. On dirait un problème dans la gestion d'utilisation des plateaux et des faces. Pour le Seagate : alors que le graphe semble normal (linéaire) coté 486, on observe une sorte d’écrêtage dans le southbrigde du PC Intel.

Débits : Sans surprise, c'est globalement mieux du coté Pentium pour les deux HDD puisque le contrôleur IDE est plus récent.

Conclusion : Remplacer le disque Conner par le Seagate serait gagnant. Par contre la limitation du BIOS à 1024 cylindres le bridera à 504Mo utilisables sur ses 850Mo.

Upgrade 486DX2-66

27/03/2017 | Informatique | 10 Commentaires

Je me suis penché sur le problème qu'avait mon PC mini-tour 486 d'époque. Je ne comprenais pas pourquoi le logiciel cachechk me disait que l'accès vers la RAM était lent et que visiblement le cache L2 n'était pas exploité à fond. J'avais donc décidé de remplacer le cache L2 et le passant de 64Ko à 256Ko par la même occasion (ayant récupéré des puces). Mais malheureusement sans solutionner le problème même si cela apportait un plus.

Cet après-midi j'ai donc fait des tests et j'ai bien vérifié l'ensemble des cavaliers de la carte mère PKM-5031Y par rapport à la documentation disponible. RAS tout est bon. J'en ai profité pour y installer le 486DX2-66Mhz d'AMD. Et là, comme par magie, plus de problème :

Le débit de la RAM est augmenté et le CPU est bien "reconnu" :

Le valeurs sont cohérentes avec le tableau indiqué sur cette page pour une configuration identique. Duke Nukem 3D s'en retrouve plus jouable même si pas tout à fait fluide.

Par contre le CPU chauffe pas mal, mais je pense que l'ancien devait arriver au même point. Impossible de laisser le doigt dessus. Je pense y mettre un ventirad.

Et je n'ai rien fait d'autre que de déplacer le cavalier pour la version DX2 (ouvrir J11) comme indiqué dans la documentation. Je ne m'explique pas pourquoi l'ancien processeur Intel DX-33 faisait dérailler l'accès L2/RAM alors que l'AMD ne pose aucun problème, j'ai interverti 2 fois les CPU et c'est systématique. Dès que l'Intel est en place, cachechk gueule. Le tout avec la même RAM. J'en viens donc à douter de l'Intel 486DX-33 d'origine. Pourtant je ne pense pas que ce soit un CPU fake pour autant.

Voilà une chose de réglée même si j'ignore vraiment pourquoi.

Quelques images de bench :

Les pics vers le bas c'est quand on joue avec le bouton Turbo

:

Sans turbo (indice 7.02) et avec turbo (24.85) :

Cloudbleed

24/02/2017 | Informatique | 2 Commentaires

Voila un des dangers de faire transiter son trafic web par un tiers. Toute la websphere en parle : la faille liée à Cloudflare découverte par Tavis Ormandy. Mon site perso est également touché et figure dans la liste, tout comme win3x.org d'ailleurs, entre autre. Puisque Cloudflare est un CDN, c'est en quelque sorte un immense reverse-proxy distribué ayant la faculté de mettre en cache en plus des données.

Le bug tel que décrit réside dans un module de parser HTML qu'ils ont écrit eux-même dans lequel il y aurait une fuite de données. Ce module est ensuite intégré dans NGINX pour faire son job (de réécriture d'URL entre autres). NGINX tourne sur les nœuds "border edge" = de sortie = ceux qui acceptent les requêtes et remettent les réponses aux clients. De ce que j'ai compris : avec un certain type de requête on peut faire "dérailler" un buffer de ce module qui pourrait renvoyer au client des informations aléatoires résiduelles en mémoire vive concernant des requêtes/transactions faites par le même serveur par d'autres utilisateurs (à coté en parallèle), et ce quelque soit le site visité.

Les informations sortent en clair et c'est normal car c'est dans une zone ou le chiffrement n'est plus.

Le chiffrement est d'une part entre le site d'origine (exemple OVH) et le serveur Cloudflare et d'autre part ensuite entre votre navigateur chez vous et le serveur Cloudflare. Le serveur Cloudflare déchiffre tout dans un sens et chiffre tout dans l'autre sens pour pouvoir faire ses traitements. C'est clairement un point sensible.

Du coup il est impossible de savoir quelles informations ont été remises à qui, et si cette personne s'en est servi ou pas. Un peut comme si votre facteur distribuait le courrier à n'importe quelle adresse de manière aléatoire. Les informations révélées peuvent donc être tout ce que vous envoyez vers un site (requêtes HTTPS), du genre :

Des morceaux de données POST, contenant éventuellement des mots de passe
Des réponses JSON d'une API
Des en-têtes HTTP
Des paramètres URI
Des cookies
Des clés API
Des jetons OAuth
Etc.

Comme Cloudflare a peut-être malheureusement redirigé ces informations vers n'importe qui à une période (depuis septembre 2016 mais surtout courant février visiblement). Le bug est corrigé mais ces données restent donc hypothétiquement dans la nature. Ces données sensibles ont parfois été mises en cache par des moteurs de recherche, elles sont donc pour certaines récupérables même si la faille a été comblée depuis. C'est pour cela que, par précaution, tout le monde vous conseille de :

modifier le mot de passe des sites hébergés qui sont derrière Cloudflare auxquels vous avez accédé, ces mots de passe ou leur hash (en espérant qu'ils soient salés, mais cela dépend des sites sur lesquels vous mettez les pieds et non de Cloudflare)
se déconnecter/se reconnecter des sites afin de faire sauter/invalider les jetons d'authentification qui ne seront plus valables pour se connecter avec votre compte à votre place.

Contrairement à ce que j'ai pu lire : non les bases de données des sites n'ont pas été hackées. C'est juste que ces infos ont fuité sur le chemin entre le site et votre navigateur.

Plus de lecture technique :