David Marec a écrit 472 commentaires

Ou, que le premier adepte invoque le démon :

#!/bin/sh
  urxvtc "$@"
  if [ $? -eq 2 ]; then
    urxvtd -q -o -f
    urxvtc "$@"
  fi

---

nécromancie numérique

A noter le démon urxvtd qui permet d'ouvrir des terminaux à la demande de
urxvtc.

Ce qui permet - en théorie, je n'ai jamais fait de mesures. - d'économiser de la mémoire et d'accélérer la création du terminal.

La réponse officielle est là:

• https://www.amd.com/en/corporate/speculative-execution

En effet, AMD insiste sur le fait que la variante 3 (Meltdown) ne les concernent pas. Enfin, AMD prétendait ne pas être concerné du tout il y a peu.

Celle d'ARM:

• http://www.arm.com/security-update

Là il existerait une variante de Meltdown qui permette d'utiliser la faille.

Plus précisément, c'est un ensemble de défauts qui conduisent à la faille.

L'exécution en avance de phase du code ne serait pas un problème si elle n'avait pas aussi provoqué une mise en cache du résultat sur l'adresse pointée.

Les attaques sur le cache sont connues depuis plus longtemps.

Je reprend un commentaire écrit dans le journal,

les auteurs de l'article qui décrit Meltdown n'ont pas aussi clairement affranchi
les autres fondeurs de la faille.

Ils expliquent seulement que leur «POC», qu'il appellent «toy» et basé sur une attaque de cache de type Flush+Reload , n'a pas
obtenu de résultat.
Seulement, leur mesures semblent indiquer que le problème existe là aussi.

Limitations on ARM and AMD:
the reasons for this can be manifold.
First of all, our implementation might simply be too slow
and a more optimized version might succeed.
For instance, a more shallow out-of-order execution pipeline could tip the race
condition towards against the data leakage.
Similarly,if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indi-
cating that out-of-order execution generally occurs and
instructions past illegal memory accesses are also per-
formed.

L’exécution d'un accès non autorisé aurait bien eu lieu sur les autres architectures, ils n'ont pas contre par réussi à sortir le résultat d'un cache.

Attention avant de conclure que seul Intel est seul concerné par Meltdown.

Les auteurs ne sont pas aussi catégoriques.

Ils expliquent juste que leur «POC» (qu'ils appellent «toy») n'a pas réussi à obtenir de résultat.
Par contre, leur tests et leurs mesures laissent supposer que c'est possible.
Il n'y sont juste pas arrivé avec leur outil, (technique de Flush+Reload que vous indiquez):

Limitations on ARM and AMD:
the reasons for this can be manifold.
First of all, our implementation might simply be too slow
and a more optimized version might succeed.
For instance, a more shallow out-of-order execution pipeline could tip the race
condition towards against the data leakage.
Similarly,if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indi-
cating that out-of-order execution generally occurs and
instructions past illegal memory accesses are also per-
formed.

Comme il existe d'autre techniques pour stresser attaquer un cache …

Bref, ce n'est pas fini.

Ceci dit une simple interdiction des appels à rdtscp (pour détecter la mise en cache) peut bloquer ce genre d'attaque.
Il semble que c'est déjà le cas de certains hyperviseurs.

Personnellement, j'ai vite investi dans le pop-corn.

D'après cette page:

https://access.redhat.com/security/vulnerabilities/speculativeexecution

Additional exploits for other architectures are also known to exist.
These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

La gamme IBM est aussi touchée.

C'est peut-là que les devs OpenBSD vont se mordre les doigts de ne pas vouloir jouer le jeu des embargos.

Mouais, enfin, sur ce coup là, ce sont les devs Linux qui n'ont pas joué le jeu, en publiant leur patchs avant l'heure.

Du coup l'embargo est levé, plus ou moins:

Google:

We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and
growing speculation in the press and security research community about the issue, which raises the risk of exploitation.
The full Project Zero report is forthcoming.

Google, par contre, ne se gêne pas pour le dire:

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

fin de l'embargo.

Oui, j'ai lu un peu vite.

Ceci dit, d'une part, ils affirment bien qu'ils ne sont pas les seuls et d'autre part, ce n'est pas leur rôle
non plus de dénoncer les copains.

Pour ce qui est de FreeBSD, ils viennent de répondre.

Pour dire … qu'ils ne peuvent rien dire.

Avec un nouveau lien en prime, la réponse de Intel.

Attention, ils indiquent qu'ils ne sont pas les seuls concernés, AMD,les ARM le seraient tout autant.

De plus, ils seraient en mesure de patcher le problème pour en atténuer les effets.

Par «lié», je ne pense pas seulement à la faille, mais à sa découverte, ou sa révélation.

D'où cette réflexion, sortie du forum FreeBSD

I think 2018 will be an EPYC year

il faut a priori partir très bas dans le fonctionnement du CPU

Tout dépend jusqu'où on peut aller, en jouant par exemple avec les macros __builtin_expect:

__predict_true()
__predict_false()

la faille serait au niveau du cœur d'exécution des micro opérations
et pas de l'exécution des instructions x86 à proprement parler

Sauf si on a empilé des instructions, qui, sans contrôle, via la TLB, pourraient sortir de l'espace utilisateur ?

Je me demande si ce n'est pas lié à l'introduction de la fonctionnalité PCID/INVPCID, qui permet, en gros, à la TLB de partager en son cache des adressages entre plusieurs processus (au lien d'un seul auparavant) et le noyau.

Donc attendons la levée de l'embargo à la con qui ne protège personne et ne fait que propager inquiétudes et rumeurs…

C'est trop tard maintenant, on peut y aller sans attendre vendredi.

Un autre lien, un peu plus précis :

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

mais qui spécule aussi surtout sur la réalité de la faille.

D'après AMD, il s'agirait d'un manque de contrôle lorsque le processeur empile de manière prédictive (speculative) les instructions avant de les exécuter (pipelining).

En bref, tout OS qui laisse l'espace utilisateur et l'espace noyau partager le même espace mémoire, le temps d'une mise en cache (TLB?) serait touché.

Il y a vraiment quelle chose là dessous, mais quoi ? pour l'instant, il faut attendre la levée de l'«embargo» pour en connaître les détails.

Comme l'aurait dit M. Cyclopède:

bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1/3 *3
.99999999999999999999
3* 1/3 
1.00000000000000000000

«étonnant, non ?»

C'est tricher.
1/3 ne peut pas être représenté par un nombre fini de chiffres.

Contrairement à 1.8 et 0.2 .

Python 2.7.12 (default, Nov 20 2017, 18:23:56) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2- (1.8 +0.2)
0.0

ou

$ bc -l 
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
2 - 1.8 -0.2
0

Serviteur.

comme exemple ultime, je m'interroge quand même : autant dans la première
je vois bien ce que ça fait même si je ne connais pas trop systemd

Si vous êtes capable de comprendre l'une vous êtes capable de comprendre l'autre, sans déconner.

Le plus important d'ailleurs, n'est il pas, non pas de la lire, mais de l'écrire;
de retrouver facilement la commande ?

Je vous invite à la lire la page de man systemctl pour la trouver.
Astuce: en fait, c'est dans man systemd.resource-control … et en partie dans systemd.slice …

A comparer avec le man rctl.

en autant je vois bien mieux à quel user ça s'adresse, pas contre les limites de 1096M sur la mémoire et les 60% de CPU,
je sèche…

C'est parce que je n'ai pas pris la peine d'écrire la commande pour le cpu ?

rctl -a user:joe:pcpu:deny=60%

C'est pas non plus strictement équivalent,

Pourquoi ça le serait ?
Dans un cas on appelle un outil conçus pour contrôler et limiter les ressources dans un autre
un outil conçu pour, euh, plein de trucs en fait.

C'est pas non plus strictement équivalent, vu que system (et Linux) est aussi capable de limiter les I/Os

Les I/Os ? quelles I/O ?

S'il s'agit des accès disques, rctl le permet avec readiops/writeiops ou readbps/writebps.

j'ai quand même le sentiment que le partage du disque va plus souvent me servir.

J'ai beaucoup de mal à voir la pertinence d'une limitation sur ces ressources, sauf peut-être dans le cas d'une jail ou
d'un process (et encore).

Si l'on veut vraiment partager son disque, on utilise des quotas.

Bon, il semble qu'il manque juste une chose : le nombre de CPU autorisés

En ce qui concerne rctl on peut définir une règle sur le pourcentage de CPU.

Si l'on veut affecter un ou plusieurs CPU à une jail, c'est le rôle de
cpuset.

rctl -a user:joe:vmemoryuse:deny=1g

Des Linux très minimaliste, il y a un savoir faire énorme.
Des solutions permettant de générer ta distribution pour une flotte de machines, ça existe aussi (Yocto).

Yocto, c'est une machinerie énorme à coté d'une poudrière, pour un résultat équivalent.

FreeBSD n'a pas beaucoup d'avantages de son côté pour ce domaine.

Il a déjà le SIGINFO.

Moi quand je lis cette règle, je me dis qu'il serait temps d'utiliser
blacklistd

#grep blacklistd /etc/rc.conf.local 
blacklistd_enable="YES"
blacklistd_flags="-r"
#grep blacklistd /etc/pf.conf
anchor "blacklistd/*" in on $ext_if

Et de se concocter un blacklistd.conf.

#pfctl -a blacklistd/22 -t port22 -T show | wc -l
      85