Reprise du message précédent :

Je comprends qu'on prend une pénalité pour chaque appel système, c'est pas que les I/O, non ?

C'est un peu plus subtil visiblement, tout ce qui va allouer/désallouer des zones mémoires rapidement (en simplifiant).

Par exemple, une compilation de noyau Linux va prendre beaucoup de CPU mais un bloc mémoire relativement fixe, très peu d'impact (cf les benchs de Phoronix). Mais un serveur web ou une DB peuvent prendre cher.

edit : ça me rappelle un peu la différence entre la virtu PV (gestion mémoire côté soft) et HVM (gestion mémoire côté hardware). Les diff de perfs sont similaires dans des cas d'utilisation proches.

kimovil.com me sort sans surprise le Mi6, le Honor 9 (on est d'accord que pour les deux 4Go de ram c'est suffisant, pas besoin de la version 6Go ) mais également le Huawei P10 Lite (moins de 200€ c'est quand même intéressant) et le Redmi 4X (100€ je trouve ça assez fou, par contre il est en 720p, est-ce que c'est gênant ?).

Les niveaux de marges ne sont pas fixes

Ah ben pour 200 euros tu auras largement quelque chose de mieux, Xiaomi fera ton bonheur
 

Ben là ça sera du Miui sous Android 7 ou 6
 

Que tu as des pb avec tes tels

c'est a dire ? tu penses qu'amazon va absorber une partie du surcout ?

Personnellement je préfère avoir du 1080p sur un tel, c'est le minimum pour pouvoir parfois lire des BD sans avoir besoin de zoomer.
 
Mais si tu n'es pas trop exigeant en téléphone, tu peux même en avoir pour 83 euros, mais après faut pas non plus leur demander la lune.
 
Sinon tu as le redmi 5 plus :  
http://sciphone.fr/vente-flash-xia [...] -a-15449e/ à 170 euros

La totalité sans doute. AWS c'est des produits à forte marge, c'est pas un problème.
Ça me semble difficile pour eux d’augmenter leurs tarifs, surtout quand les gros clients ont souvent des instances réservées donc avec des engagements tarifaires contractuels.
En tant qu'utilisateur final, tu payes Amazon pour un service, si Intel fait de la merde c'est pas ton problème.

Le moment ou je viens de changer pour un pti ryzen
 

 
A 15/30% de perte de perf, c'est franchement pas dit, et les nouveaux clients eux auront certainement le droit a un prix mis a jour en conséquence...

Ce que je comprends de l'article, c'est que normalement, un fantôme d'interruption du kernel existe dans l'espace d'adressage de chaque appli (ce que je ne savais pas). Vu que les interruptions sont permanentes, j'imagine que le code est normalement loadé en cache processeur. Or là, la faille d'Intel permet d'aller taper dans l'espace du noyau depuis l'espace utilisateur, et la seule parade semble être d'empêcher de loader ces fantômes dans l'espace d'adressage (mais normalement non accessible depuis le mode user), et de garder le code du noyau dans son espace complètement séparé. L'impact est donc énorme puisqu'il nécessite de recharger depuis la RAM le code de context switching à chaque interruption.
Ca pue du cul.

Apparemment ils ont eu le problème il y a quelques années sur Bulldozer, avec sensiblement le même résultat.

Non mais c'est d'assez loin le plus problématique, la majorité des syscalls sont soit peu fréquents soit groupables (genre les allocations dans une boucle tu peux te faire une freelist ou truc du style, et ton allocateur en a probablement une de toute manière, il va pas faire un sbrk/mmap à chaque malloc).

L'autre grosse merde potentielle c'est le bon vieux gettimeofday(2), qui est connu pour être assez lent (par rapport à l'attente des gens) et est le use-case originel des vsyscalls & vDSO (il est d'ailleurs mentionné explicitement comme motivation des vDSO). Idem pour OSX et le commpage.

La majorité des allocateurs font de la mitigation et n'ont pas un mapping 1:1 entre malloc/free et les syscalls, ils font des préallocations de blocs (arenas), ils ont des freelists/caches, …

En attendant ça pique fort : https://www.phoronix.com/scan.php?p [...] 6pti&num=2

Ca a l'air effectivement d'impacter surtout les I/O et les accès mémoire (ou les allocations ?), donc ma compréhension du problème depuis l'article n'est probablement pas très bonne.

ça impacte les syscalls (en entrée et en sortie: user->kernel et kernel->user)

Apparemment ça a aussi un impact relativement long post-syscall parce que la mitigation (linux en tout cas) doit flusher un cache, sauf si le CPU est suffisamment récent. Je retrouve plus le lien.

il y a changement de contexte (addresse space) donc on doit flusher le TLB (le cache des translation virtuel -> physique) donc oui le flush prend lui-même du temps et en plus on a perdu le contenu du cache quand on revient en user...

 
Chaque application dispose de sa propre table des pages gérée par la MMU (matériel) et l'OS.
 
La table des pages d'un processus contient :
    -les mappings @ virtuelles du processus -> @ physiques.
    -les mappings @ virtuelles du code de l'OS -> @ physiques.
 
Le mapping du code de l'OS @virt -> @phys est le même pour tous les processus et ce qui empêche l'application de lire/écrire/exécuter le code noyau c'est que dans les mappings les @ de pages noyau sont mappées avec des droits spécifique Supervisor (Bit S/U dans la Page table entry).
 
-Quand une apps s'exécute elle s'exécute avec les droits user si elle accede a une page mappée avec les droits noyau => Page fault.
-Quand il y'a une interruption ou un syscall le processeur bascule en mode Supervisor et execute le code de la routine d'interruption qui est enregistré sous la forme d'une adresse virtuelle qui pointe vers une page placée dans un mapping accesible que au noyau.
 
Le BUG à pour conséquence que dans certains cas la MMU ne va pas faire son tafe et ne vas pas lever d'exception lors d'une lecture à une page mappée avec des droits Supervisor. => Protection des droits en lecture par la MMU out.
 
La solution : avoir 2 tables des pages une pour le noyau une pour l'application.
-Une application ne peut acceder a une page physique si elle n'est pas mappée en mémoire.
-Si les pages du noyau ne sont pas mappées elle ne sont donc pas accessibles
 
Problèmes:
    - Flush de TLB entre deux changement de table des pages sauf si présence de Process-Context Identifier (http://forum.osdev.org/viewtopic.php?f=1&t=29935) Une fonctionnalité qui permet d'associer un ID a chaque entry dans la TLB. Du coup quand y'a un lookup dans le cache pour depuis une @virt récupérer une @physique le processeur va regarder si le PCID courant en plus de l'@ virtuelle.
    - Le noyau a besoin d'accéder à des pages mémoire mappée en user mode pour, par exemple récupérer les parametres de certains sycalls => maintenir un double mapping des tables des pages ?? => Dans tous les cas on le paye avec des TLB MISS en plus car une page est alors mappée deux fois avec des PCID différents.
    - Certains structures (Gates) de contrôle du noyau doivent être forcémment présentes dans la table des pages de l'application. Tout ce qui est gates notamment pour les interruptions (IDT) qui servent à pointer sur les routines de gestion des interruptions doivent être mappés dans l'espace mémoire de l'application. Comme le bug se produit uniquement en lecture ses pages peuvent être laissées dans l'espace utilisateur. Si le même BUG avait eu lieu en écriture c'aurait été la fin des haricots .
 
Ce qui est FUN c'est que sous ARMV7 les mecs avait de manière matérielle prévu de pouvoir utiliser 2 tables des pages une pour le noyau une pour les applications mais que Linux ne l'utilisait pas.

De ce que je comprends.
 
https://cyber.wtf/2017/07/28/negati [...] user-mode/
 
Avant quand une appli demande un accès à un espace mémoire, les intructions de intel test si l'espace mémoire demandé n'est pas une addresse appartenant au kernel. Ce test peut prendre un certain nombre de temps et en attendant il est toujours possible d'éxécuter un certains nombres instructions (spéculative instructions). Si le test foire, le proc lève une exception et vide l'ensemble de la pile des instructions.
 
Sauf que entre temps l'état du processeur, ses caches ont pu être modifiers par nos spéculatives instructions. Ce que raconte l'auteur de l'article c'est qu'en analysant l'état du cache il est théoriquement possible de retrouver les addresses qui ont réussit le test et donc en déduire celles appartenant au kernel.

C'est à ca que je pensais mais ne retrouvais pas au dessus

Merci pour tes conseils, je vais comparer ça tranquillement ce week-end. J'ai récupéré un Oneplus 3T du boulot pour le moment. Je le trouve beaucoup trop grand mais la différence de réactivité avec le Oneplus X est saisissante !

Edit : exit le Redmi 5, 5.99" bordel

Merci.  

Je viens de découvrir cet article qu'est vraiment bien écrit: https://lwn.net/Articles/738975/
 
Il date de 2017 et ne parle donc pas du bug qui n'avait pas en fuité mais du dev effectué par Linux pour avoir deux tables des pages.

oui ce problème est connu (présentation d'une équipe autrichienne au 34C3), c'est une attaque de style side-channel/timing attack.  
 
Si ce n'est que ça ce n'est pas si grave que ça: il y a des fuites d'info qui permettraient d'exploiter plus facilement une faille existante, mais aucune faille directe, et aucun accès en lecture au data protégées.  
 
Sauf que ça a l'air plus grave que ça vu la précipitation à mettre un patch qui pénalise séverement les performances....

Oui, c'est une attaque de type retour sur interruption/exploit du bug de la MMU , j'ai l'impression.

la réponse dans quelques jours...

https://twitter.com/BryanLunduke/st [...] 7266042880 pendant ce temps la, ca balance

 
C'est sur une branche perso, je ne l'ai pas retrouvé sur le repo officiel.
Quelqu'un peu me résumer l'histoire très rapidement ?

Cf commentaires au dessus. Bug dans l'implémentation (de l'exécution spéculative?) chez Intel (tous les CPU produits depuis 12 ans sont affectés) qui permet à un process USER d'accéder à la mémoire noyaux, ça semble également affecter les superviseurs (en tout cas certains) et permettre de sortir de sa VM.

 
https://www.dealabs.com/bons-plans/ [...] 20-1095339
 
5.2 pouces, RAM et stockage de fou, rapide, plutôt joli.
 
3  bémols plus ou moins emmerdants :
 
* ROM en anglais / chinois seulement, et des trucs qui restent en chinois (genre l'affichage du nom de la région en chinois dans l'appli de téléphone, mais bon)
* Fâcheuse tendance à killer les apps en arrière plan pour gagner de la batterie (quand c'est le réveil, ça peut être chiant, mais c'est réglable)
* problème de synchronisation des contacts qui oblige à DL une app de Google (Google Contacts Updater) régulièrement (j'ai dû la mettre à jour 3 fois depuis que je l'ai)
 

 
Merci
 

 
Prix intéressant effectivement
Après pour 300€ le Honor 9 ou le Mi6 me font de l’œil quand même, ils ont l'air assez foufou

-10% sur les actions Intel et +15% AMD dès demain

Muchacho

https://www.bloomberg.com/news/arti [...] essor-flaw

D'ailleurs https://www.fool.com/investing/2017 [...] stock.aspx
Quelle étrange coincidence

Je me demande ce qui se serait passé si le bug avait été en écriture et donc sans aucune possibilité de patch .

P-ê qu'il l'est et qu'on ne le sait pas parce que c'est gardé ultra secret.

le patch est de séparer user et kernel dans des espaces mémoires différents. Donc même s'il y a un bug en écriture le patch fait le job.

 
Non pour x86-64 il n'ya pas de mécanisme HW qui permet de switcher de table des pages sur interruption/sys call. Il faut que le gestionnaire d'interruption soit mappé par la table des pages du processus courant qui va handler l'interruption.
 
https://lwn.net/Articles/738975/  
 
-"The minimal kernel page tables try to map only what is needed to enter/exit the kernel such as the entry/exit functions, interrupt descriptors (IDT) and the kernel trampoline stacks."
 
-"The second "shadow" page table contains a copy of all of the user-space mappings, but leaves out the kernel side. Instead, there is a minimal set of kernel-space mappings that provides the information needed to handle system calls and interrupts, but no more. "
 
Ce gestionnaire d'it est protégé de l'application par la MMU. Le fait que l'application puisse y accéder en lecture posse certains légers problèmes :
 
-"This minimal set of data can still reveal the kernel's ASLR base address. But, this minimal kernel data is all trusted, which makes it harder to exploit than data in the kernel direct map which contains loads of user-controlled data"
-" While the patch does not mention it, one could imagine that, if the presence of the remaining information turns out to give away the game, it could probably be located separately from the rest of the kernel at its own randomized address. "
 
Par contre si une application peut réécrire son propre gestionnaire d'it alors elle peut prendre le contrôle de la machine sur interruption en injectant son code dans le handler d'it qui sera exécuté en mode superviseur.
 
Et contre ça je ne vois pas de solution.
 
Je crois que ARM permet de gérer 2 tables des pages de manière totalement HW avec le matériel qui va bien pour faire le switch de table des pages automatiquement sur interruption.

ah oui effectivement... on pourrait attaquer le handler d'it... enfin l'attaque serait difficile quand même puisqu'il faudrait faire une attaque supplémentaire (handler d'it puis kernel)

J'ai spéculé sur ça, ça a plutôt bien marcher, par contre je sais pas trop quand withdraw  

 
Une fois que le handler d'interruption est réécrit il est exécuté en mode superviseur. Le code à le contrôle sur la machine il peut mapper les pages de mémoire physique qu'il veut pour accéder aux données du kernel.