COMPTOIR
  
register

Composé par ————— —— 32714 vues

Une solution aux failles liées à l'exécution spéculative ?

Avec la série de failles récentes découlant de Meltdown et Spectre, bon nombre d'industriels ont dû avoir froid dans le dos. Il faut dire que malgré les fix (parfois coûteux en performances) proposés par les constructeurs, de nouvelles vulnérabilités se basant sur le même principe sont découvertes régulièrement, signe d'une faiblesse de design relativement profonde. Des chercheurs de l'université de Californie se sont ainsi penchés sur une modification simple des circuits actuels dans le but d'éviter tout problème liés à l'exécution spéculative.

 

spectre logo

 

Si, du côté privé, un fix matériel est bien sur les rails, aucune information technique n'a été communiquée à ce sujet ; et selon certaines discussions avec des ingénieurs schtroumpf, le patch proposé par Google pour contrer Spectre (les fameux retpolines) pourrait même être inefficace pour les prochaines architectures du fondeur de Santa Clara !

 

La solution proposée consiste simplement à rajouter une structure annexe dans laquelle sont stockées les informations chargées spéculativement, qui est ensuite validée ou jetée selon que la prédiction se soit révélée juste ou fausse. Selon leurs simulations, aucune perte de performance ne serait à déplorer, mais cela est très biaisé étant donné que ces changements induisent une augmentation la taille totale de cache disponible, ce qui est peu probable pour les prochaines générations de processeurs dans un futur proche.

 

spectre safespec modifications

En gris, les modifications nécessaires : ajout d'un cache supplémentaire au niveau de chaque cache, TLB inclus

 

Par ici le papier !
Un poil avant ?

Pascal à n'en plus pouvoir : deux nouvelles GTX 1050 3Go chez GIGABYTE

Un peu plus tard ...

Le tout premier Cannon Lake disséqué !

Les 24 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Borny, le Mardi 19 Juin 2018 à 14h09  
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 21h48
Pas spécifiquemnt du C/C++ mais plutôt du client lourd.
Mouais, sauf que le client lourd n'est pas adapté à toutes les situations.
Typiquement, je me vois mal devoir installer un client lourd pour accéder aux sites des impôts, de ma banque, de tous les sites d'informations, forum...

J'ai travaillé pour MMA, pourquoi ce casser la tête avec le déploiement de toutes les nouvelles version des logiciels utilisés par les milliers d'agents tous les mois (enfin, je ne connais pas la fréquence exacte), quand il suffit simplement de déployer les livrables sur les serveurs. (Et là, on parle de pleins de techno différentes en fonction des sous-parties de l'application principale... des pages web, des interfaces en lignes de commande... Un joli bordel)

Après, pour un usage spécifique : typiquement bornes SNCF / DAB... Oui, encore que, l'interface peut très bien être une page Web légère, le serveur derrière servant à gérer les interactions entre les billets et le SI entre les banques...

Faire du client lourd pour faire du client lourd ça n'a pas de sens. Ce serait comme développer Half Life 3 en javascript (à part pour le défi/se faire plaisir...).

D'une certaine façon, un navigateur est un client lourd. Alors oui, c'est sûr qu'étant un logiciel qui doit s'adapter à des technos/normes "monstrueuses" (html/css/js... c'est déjà un joli pavé ), il est logique qu'il doivent jouer avec des dizaines de Mo pour tourner. C'est même d'ailleurs assez léger 20 Mo pour une page web ultra simple. Et il est sûr que l'on pourra faire plus léger avec un client lourd "mono-tâche".
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 21h48  
par Borny, le Lundi 18 Juin 2018 à 18h50
Qu'entends-tu par "développeur" complet ? Un développeur qui code en C/C++ ?
Pas spécifiquemnt du C/C++ mais plutôt du client lourd.
par Borny, le Lundi 18 Juin 2018 à 18h50  
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 17h06
Effectivement l'environnement d'un développeur web est le navigateur tandis que celui d'un programmeur "complet" c'est le système d'exploitation.
Ce n'est pas aussi simple.
Personnellement, dans mon travail, je ne connais pas de développeur Web qui ne fait strictement que de l'IHM.

Pour mon cas, je ne travaille pas seulement sur la partie web/IHM/ce qui est affiché par le navigateur.
Tu oublies qu'un site Web a toujours une partie serveur, qu'elle soit légère ou complexe. Derrière ce serveur on peut avoir des dizaines de Webservices permettant d'accéder à des bases de données, ou d'autres Webservices de fournisseurs... Voire de l'orchestration de Webservices avec des transactions à gérer (si une maj sur un des ws plante d'un SI plante, il faudra annuler ce qui a déjà été fait sur les autres SI par exemple...).

Qu'entends-tu par "développeur" complet ? Un développeur qui code en C/C++ ?
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 17h06  
par Borny, le Lundi 18 Juin 2018 à 11h48
Très bien.
Expliques-moi donc comment faire pour faire pour qu'une page web de 66 octets sans autre ressource consomme moins de 20 Mo de mémoire vive sur Chrome ?
Tu poses le mauvais diagnotic. Le travail du programmeur est de proposer une solution technique logicielle et l'imposition d'un navigateur, framework voir tout simplement d'une solution web est une absurdité malheureusement bien présente dans la tête des donneurs d'ordre qui se font bourrer le mou par des commerciaux ou managers qui n'ont aucune compétence technique.

 

A titre d'info, la même page consomme 25-30 Mo de mémoire avec IE.


Rien de bien surprenant au regard de la composition d'une page web et des caractéristiques du moteur de rendu.

 

Qu'est-ce que je peux faire pour que ces navigateurs consomment moins de ressource système sur un exemple aussi simple ?


Rien puisque le développeur web subit l'environnement du navigateur mais aussi de son implémentation au regard du système d'exploitation et de sa gestion mémoire.

C'est grosso modo une double punition au bénéfice d'une absence de gestion mémoire de la part du programmeur, or de mon point de vue ce qui différencie le programmeur du graphiste c'est spécifiquement la gestion de la mémoire dont sont majoritairement issus les bugs.

 

Un développeur web n'a pas gérer comment le navigateur utilise les ressources systèmes.

Mais bon


Effectivement l'environnement d'un développeur web est le navigateur tandis que celui d'un programmeur "complet" c'est le système d'exploitation.
par Borny, le Lundi 18 Juin 2018 à 11h48  
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h37
Si tu le dis... c'est que cela doit être vrai... pour toi.
Très bien.
Expliques-moi donc comment faire pour faire pour qu'une page web de 66 octets sans autre ressource consomme moins de 20 Mo de mémoire vive sur Chrome ?
A titre d'info, la même page consomme 25-30 Mo de mémoire avec IE.

Qu'est-ce que je peux faire pour que ces navigateurs consomment moins de ressource système sur un exemple aussi simple ? Un développeur web n'a pas gérer comment le navigateur utilise les ressources systèmes.

Mais bon
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h37
Si tu le dis... c'est que cela doit être vrai... pour toi.
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h37  
par Borny, le Lundi 18 Juin 2018 à 11h19
Est-ce dû fait du développeur Web ? Non.
Si tu le dis... c'est que cela doit être vrai... pour toi.

 

Pourtant, c'est toi qui allume gratuitement les développeurs Web et les entreprises les employant.


Il n'y a pas de sous-métier... il ne faut pas avoir honte de remplir son réfrigérateur à produire de la m*** 7 h/j parce que c'est ce que souhaite le marché.

Les ouvriers chinois le font bien alors pourquoi pas les programmeurs (ouvriers 2.0) français?
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h28  
par Un adepte de Godwin embusqué, le Lundi 18 Juin 2018 à 08h57
parles pour toi, de quel droit tu te permets de faire des generalités comme ca, tu crois que tous les devs web sont amateurs ?
Je n'ai jamais tenu un tel propos néanmoins le profil typique du programmeur français est plutôt jeune et peu expérimenté employé par une société de services informatiques (aka marchand de viande ou SSII) réalisant principalement du développement web pour limiter les coûts sociaux chez le client/prestataire bien que pas smicard mais largement sous-rémunéré comparativement à des programmeurs seniors plus expérimenté sur des applications plus critiques mais peu employable/exploitable.

 

tu dois pas connaitre grand chose au monde du web pour en parler comme ca ... abstiens toi a ce niveau tu saouleras moi les gens


Si tu le dis... c'est que cela doit être vrai... pour toi.
par Borny, le Lundi 18 Juin 2018 à 11h19  
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h10
La formulation de ton propos réalisant une comparaison ridicule entre la taille du code source et l'utilisation mémoire réalisée par le navigateur après rendu laisse l'entendre... autrement il aurait mieux valu s'abstenir de tenir un tel propos.
Ça signifie surtout que le navigateur (Chrome dans mon exemple, donc un processus par onglet, un par extension + un pour les gouverner tous) a besoin de plus de 20 Mo de mémoire pour le moteur et tout ce qui va avec pour afficher une page Web des plus simples avec un titre et un mot dans feuille style, images, scripts...

Est-ce dû fait du développeur Web ? Non.

Pourtant, c'est toi qui allume gratuitement les développeurs Web et les entreprises les employant.
par Un ragoteur sans nom embusqué, le Lundi 18 Juin 2018 à 11h10  
par Borny, le Dimanche 17 Juin 2018 à 18h47
Où ai-je dis ça ? Merci pour les raccourcis débiles...
La formulation de ton propos réalisant une comparaison ridicule entre la taille du code source et l'utilisation mémoire réalisée par le navigateur après rendu laisse l'entendre... autrement il aurait mieux valu s'abstenir de tenir un tel propos.
par Un adepte de Godwin embusqué, le Lundi 18 Juin 2018 à 08h57  
par Un ragoteur sans nom embusqué, le Dimanche 17 Juin 2018 à 16h01
Le problème c'est que le développeur web ne comprend pas grand chose à la programmation (architecture matérielle, gestion mémoire, algorithmie, etc) sinon faire du copier-coller...

La faute aux entreprises qui souhaitent niveler par le bas les coûts sociaux en payant au lance-pierre des monkey coders.

Ce n'est pas très compliqué à comprendre étant donné que le développeur web délègue la gestion mémoire comme un conducteur peut déléguer la gestion des rapports par une boite automatique, cela a un coût.

Une preuve de plus que le développeur web n'a aucune notion de gestion mémoire puisqu'il considère que le rendu d'une page web ne devrait pas occuper plus de mémoire que le contenu de son code HTML.
parles pour toi, de quel droit tu te permets de faire des generalités comme ca, tu crois que tous les devs web sont amateurs ? tu dois pas connaitre grand chose au monde du web pour en parler comme ca ... abstiens toi a ce niveau tu saouleras moi les gens
par Borny, le Dimanche 17 Juin 2018 à 18h47  
par Un ragoteur sans nom embusqué, le Dimanche 17 Juin 2018 à 16h01
Le problème c'est que le développeur web ne comprend pas grand chose à la programmation (architecture matérielle, gestion mémoire, algorithmie, etc) sinon faire du copier-coller...

[...]

Ce n'est pas très compliqué à comprendre étant donné que le développeur web délègue la gestion mémoire comme un conducteur peut déléguer la gestion des rapports par une boite automatique, cela a un coût.
En même temps, avec la gestion mémoire déléguée au système, le développeur peut se concentrer sur le principal.
Ce qui ne veut pas forcément dire coder n'importe comment... Et c'est certain que c'est une dérive possible.

Soyons clair, ça ne fait pas parti des priorités du client.

Si on parle de la partie client, le développeur n'a pas la main sur la gestion des ressources système par le navigateur.
Bien sûr, s'il y a une gestion javascript côté client, il est responsable de ce code, sa complexité..., mais pas de comment le navigateur le gère.
par Un ragoteur sans nom embusqué, le Dimanche 17 Juin 2018 à 16h01
Une preuve de plus que le développeur web n'a aucune notion de gestion mémoire puisqu'il considère que le rendu d'une page web ne devrait pas occuper plus de mémoire que le contenu de son code HTML.
Où ai-je dis ça ? Merci pour les raccourcis débiles...
par Un ragoteur sans nom embusqué, le Dimanche 17 Juin 2018 à 16h01  
par Borny, le Samedi 16 Juin 2018 à 21h24
Perso, je développe des outils accessibles en intranet, des pages web.
Je ne comprends pas comment les pages que l'on code, aussi légères soit-elles, peuvent consommer des centaines de Mo de ressource système.
Le problème c'est que le développeur web ne comprend pas grand chose à la programmation (architecture matérielle, gestion mémoire, algorithmie, etc) sinon faire du copier-coller...

La faute aux entreprises qui souhaitent niveler par le bas les coûts sociaux en payant au lance-pierre des monkey coders.

 

=> ce ne sont pas les quelques ko de html/js que peuvent peser une page web qui peuvent expliquer les centaines de Mo de mémoire nécessaires, même si on ajoute quelques centaines de ko d'image (les pages que je développe ne contiennent jamais de photos ou autre image "complexe", au pire ce sont des icônes).


Ce n'est pas très compliqué à comprendre étant donné que le développeur web délègue la gestion mémoire comme un conducteur peut déléguer la gestion des rapports par une boite automatique, cela a un coût.

 

Juste par curiosité, je viens de faire une page html avec seulement un titre "page web" et pour contenu le mot "body". ça consomme déjà 21 876 ko dans Google Chrome pour une simple page html de 66 octets !!!


Une preuve de plus que le développeur web n'a aucune notion de gestion mémoire puisqu'il considère que le rendu d'une page web ne devrait pas occuper plus de mémoire que le contenu de son code HTML.