Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
Non, la banquière était la responsable entreprise.
Dans le cas de librapay, ou il y a transfert d'argent, il faut être certifier PCI-DSS pour conserver l'argent de personne pour ensuite, le redistribuer. Je connais Lemonway dans le lot.
En général une banque ne propose pas d'API. Quand j'ai parler de ça à une banquière, elle m'a dit : "oui vous avez une interface web pour envoyer votre fichier de paiement chaque mois…"
UEFI n'est pas utilisé sur ARM, à ma connaissance, et n'est pas du tout rendu obligatoire par un standard quelconque. La norme PCI est un bon exemple, mais cela n'est jamais utilisé dans un SoC. le device tree ne répond pas au problème. Est-ce que l'on imagine un device-tree pour chaque combinaison de hardware pour un PC ?
Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner.
Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.
Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".
Si il pouvait aussi spécifier le boot loader… Linux a seulement besoin de l'horloge, d'une liaisons série, et de DRAM fonctionnelle (certain plateforme nécessite d'écrire une configuration dans le contrôleur DRAM qui utilise par défaut des valeurs conservatrices très lente), à cela il faut rajouter une table standard pour identifier les périphériques sur le bus (comme pour le PCI) et c'est bon (il faut juste une adresse mémoire + un numéro d'identification unique).
On peut rajouter à tout ça un boot USB et/ou SD pour démarrer une première fois, et l'on a tout ce qu'il faut non ?
Je ne sais pas si cela a changé, mais un des énormes problèmes de ARM est l'absence d'un équivalent au bios, qui permet la détection des périphériques. Cela rend totalement impossible d'avoir un binaire universel ARM pour Linux, par exemple.
Le deep learning, qui a relancé la mode de l'IA, c'est la détermination automatique des "features" avec l'aide de beaucoup d'exemples (big data) ou d'un simulateur (cf alphazero).
En tout cas, vous êtes dans le cas idéal pour utiliser les CPU à fond : localité d'accès + pas d'IO + vectorisation.
Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.
Je ne sais pas pour l'AVX, mais sur un cpu x86 64 bits, le code FPU x87 est remplacé par les instructions "scalaire" SSE. De mémoire, c'est AMD qui avait rendu obligatoire le support SSE 2.1 pour son 64 bits, repris par intel. Je ne pense pas que l'unité SIMD peut être utilisé par morceau.
Je me demande si c'est toujours vrai avec du code du monde réel. Car le cas que tu décris est celui ou le cache est toujours utilisé. Le moindre cache miss, c'est des centaines de cycle de perdu, qui peuvent être un peu récupéré par de l'hyperthreading (ex: un code d'IO qui n'utilise pas la FPU).
"Tout n'est donc pas corrigeable par du micro-code, pire, c'est en partie l'architecture du processeur qui est à repenser et donc il faudra des années avant que ne sorte des processeurs fiable…"
Pas vraiment, il est tout à fait possible pour Intel de fournir un petit peu de contrôle sur le truc, un peu comme le verrouillage de mémoire pour éviter de swapper des clefs sur le disque dure. Après je ne connais pas les détails de l'attaque mais en général, le principe de la défense est que le timing ne dépend plus des données.
L'erreur de l'article est de croire que les utilisateurs finaux ont le même niveau de compétence OS que l'hébergeur. Je pense qu'en moyenne, c'est complètement faux. Certains fournisseurs de cloud patchent leur noyau avant la sortie des noyaux officiels.
Le principe même du SMT, c'est de partager des ressources processeurs entre 2 processus. Car avec d'énormes pipelines (~ 30 étages) et 5 unités en parallèle, il y a souvent des "bulles", des bouts de pipelines "vides". En moyenne, il y a un ipc de 3, cela veut dire 3 instructions exécutés, cela laisse ~40% d'inactivités.
Le SMT permet d'utiliser ces cycles inutilisés. Cela n'est pas idiot. Le gain est bien plus faible à cause de la pression sur les caches. En jouant 2 processus, on tue la localité des données. D'où le fait que les premier SMT utilisant 4 threads puis Intel est passé à 2.
AMD dans ses bulldozers, a fait un truc intermédiaire : dédier des ALU et pas seulement des bancs de registres. L'erreur a été de faire croire que c'était des vrai cpu complet.
D'un point de vue sécurité, c'est toujours du partage de ressource. Donc, si on peut mesurer les performances, on peut savoir l'usage des ressource de l'autre thread, ce qui est clairement une attaque side-channel.
La France a peur, et a donc des réflexes de repli. Ce n'est pas les politiques qu'il faut convaincre sur les lois, c'est Mme Michu. Les politiques suivent le sens du vent.
Je me suis toujours demandé si un modèle de map() mais parallèle aurait du sens. L'idée est de faire comme la nursery mais avec synchronisation sur les données de sortie. En gros, le code de la branche principal tourne jusqu'à une tentative de lecture d'une sortie de la tache asynchrone. Ainsi, c'est le graphe de dépendance des variables qui fait la synchro des tâches (sender non-bloquant, receiver bloquant en communication par message).
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Je pense à un système beaucoup plus petit. La table dont je parle pourrait faire pas plus de qq ko. Il faut juste que l'adresse soit fixe.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3. Dernière modification le 12 juillet 2018 à 08:52.
pour une utilisation perso sans doute, pro, je doute beaucoup plus.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 5.
Non, la banquière était la responsable entreprise.
Dans le cas de librapay, ou il y a transfert d'argent, il faut être certifier PCI-DSS pour conserver l'argent de personne pour ensuite, le redistribuer. Je connais Lemonway dans le lot.
"La première sécurité est la liberté"
[^] # Re: Stripe ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
lemonway avait (a?) un payback de 30€, ce qui le rend impossible à utiliser pour des petits montants.
Pour Strip, je vois 1.4%+0.25€ de frais CB contre 1.8%+.18€ de frais pour Mangopay, on est pas au double, ou alors, j'ai oublié un truc ?
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 7.
En général une banque ne propose pas d'API. Quand j'ai parler de ça à une banquière, elle m'a dit : "oui vous avez une interface web pour envoyer votre fichier de paiement chaque mois…"
"La première sécurité est la liberté"
[^] # Re: Stripe ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
pas mal dans quel sens ? Il gère des comptes chez eux ?
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
En fait, c'est l'inverse. Car ils rendent la gestion du logiciel, infiniment plus complexe. Et l'ISA, c'est du logiciel.
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
UEFI n'est pas utilisé sur ARM, à ma connaissance, et n'est pas du tout rendu obligatoire par un standard quelconque. La norme PCI est un bon exemple, mais cela n'est jamais utilisé dans un SoC. le device tree ne répond pas au problème. Est-ce que l'on imagine un device-tree pour chaque combinaison de hardware pour un PC ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner.
Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.
Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 6.
Si il pouvait aussi spécifier le boot loader… Linux a seulement besoin de l'horloge, d'une liaisons série, et de DRAM fonctionnelle (certain plateforme nécessite d'écrire une configuration dans le contrôleur DRAM qui utilise par défaut des valeurs conservatrices très lente), à cela il faut rajouter une table standard pour identifier les périphériques sur le bus (comme pour le PCI) et c'est bon (il faut juste une adresse mémoire + un numéro d'identification unique).
On peut rajouter à tout ça un boot USB et/ou SD pour démarrer une première fois, et l'on a tout ce qu'il faut non ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10. Dernière modification le 11 juillet 2018 à 11:01.
Je ne sais pas si cela a changé, mais un des énormes problèmes de ARM est l'absence d'un équivalent au bios, qui permet la détection des périphériques. Cela rend totalement impossible d'avoir un binaire universel ARM pour Linux, par exemple.
"La première sécurité est la liberté"
[^] # Re: Heuristique
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage pour vous, un logiciel d'intelligence artificielle, c'est quoi ?. Évalué à 5.
Le deep learning, qui a relancé la mode de l'IA, c'est la détermination automatique des "features" avec l'aide de beaucoup d'exemples (big data) ou d'un simulateur (cf alphazero).
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 4.
En tout cas, vous êtes dans le cas idéal pour utiliser les CPU à fond : localité d'accès + pas d'IO + vectorisation.
Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 3.
Il y a aussi beaucoup de simulateur qui crache beaucoup de log, ou qui font des checkpoints pour reprendre leur travaux en cas de crash.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 3.
Peu d'IO alors ?
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 3. Dernière modification le 26 juin 2018 à 19:38.
Il n'utilise pas beaucoup de mémoire ?
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 2.
Je ne sais pas pour l'AVX, mais sur un cpu x86 64 bits, le code FPU x87 est remplacé par les instructions "scalaire" SSE. De mémoire, c'est AMD qui avait rendu obligatoire le support SSE 2.1 pour son 64 bits, repris par intel. Je ne pense pas que l'unité SIMD peut être utilisé par morceau.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 4.
Je me demande si c'est toujours vrai avec du code du monde réel. Car le cas que tu décris est celui ou le cache est toujours utilisé. Le moindre cache miss, c'est des centaines de cycle de perdu, qui peuvent être un peu récupéré par de l'hyperthreading (ex: un code d'IO qui n'utilise pas la FPU).
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 3.
Pas vraiment, il est tout à fait possible pour Intel de fournir un petit peu de contrôle sur le truc, un peu comme le verrouillage de mémoire pour éviter de swapper des clefs sur le disque dure. Après je ne connais pas les détails de l'attaque mais en général, le principe de la défense est que le timing ne dépend plus des données.
"La première sécurité est la liberté"
[^] # Re: Pas convaincant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Surface d'attaque des serveurs dans les nuages (cloud). Évalué à 4.
L'erreur de l'article est de croire que les utilisateurs finaux ont le même niveau de compétence OS que l'hébergeur. Je pense qu'en moyenne, c'est complètement faux. Certains fournisseurs de cloud patchent leur noyau avant la sortie des noyaux officiels.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 8.
Le principe même du SMT, c'est de partager des ressources processeurs entre 2 processus. Car avec d'énormes pipelines (~ 30 étages) et 5 unités en parallèle, il y a souvent des "bulles", des bouts de pipelines "vides". En moyenne, il y a un ipc de 3, cela veut dire 3 instructions exécutés, cela laisse ~40% d'inactivités.
Le SMT permet d'utiliser ces cycles inutilisés. Cela n'est pas idiot. Le gain est bien plus faible à cause de la pression sur les caches. En jouant 2 processus, on tue la localité des données. D'où le fait que les premier SMT utilisant 4 threads puis Intel est passé à 2.
AMD dans ses bulldozers, a fait un truc intermédiaire : dédier des ALU et pas seulement des bancs de registres. L'erreur a été de faire croire que c'était des vrai cpu complet.
D'un point de vue sécurité, c'est toujours du partage de ressource. Donc, si on peut mesurer les performances, on peut savoir l'usage des ressource de l'autre thread, ce qui est clairement une attaque side-channel.
"La première sécurité est la liberté"
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 9.
Ils cherchent avant tout à se faire réélire, il ne faut pas oublier.
"La première sécurité est la liberté"
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 5.
La France a peur, et a donc des réflexes de repli. Ce n'est pas les politiques qu'il faut convaincre sur les lois, c'est Mme Michu. Les politiques suivent le sens du vent.
"La première sécurité est la liberté"
[^] # Re: Communauté et bibliothèques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La programmation concurrente en mode Goto. Évalué à 3.
Je me suis toujours demandé si un modèle de map() mais parallèle aurait du sens. L'idée est de faire comme la nursery mais avec synchronisation sur les données de sortie. En gros, le code de la branche principal tourne jusqu'à une tentative de lecture d'une sortie de la tache asynchrone. Ainsi, c'est le graphe de dépendance des variables qui fait la synchro des tâches (sender non-bloquant, receiver bloquant en communication par message).
"La première sécurité est la liberté"