Guillaume Knispel a écrit 2474 commentaires

Concernant la précision en calcul FPU sur x86, elle est la plupart du temps concrètement limitée à 64-bits (lors des sauvegardes des registres en mémoire) de toute façon.

Si t'utilises un OS libre tu peux sûrement te servir des trucs TPM and co en les contrôlant complètement toi-même. Pour les trucs de sécurité à distance, les BIOS ont typiquement une option de désactivation irréversible sans doute car beaucoup de grosses boites considèrent ça comme un risque dans certains cas (même si je ne sais pas comment cette désactivation irréversible est implémentée, il faudrait reverse chaque bios différent pour en être sûr, d'un autre côté si on est parano il faudrait déjà reverse chaque bios pour vérifier l'absence de backdoor par toutes les autres manières possible, ainsi que reverse le hard pour vérifier l'absence de backdoor matérielle)

Mais si on veut filmer+encoder un truc a l'arrache en temps réel c'est ptet intéressant niveau conso ?

Ça serait bien que les processeurs proposent une option avec laquelle ils indiquent à l'OS quel est l'espace nécessaire pour sauvegarder tous les registres des extensions, et une instruction pour le faire, histoire d'éviter d'avoir a ajouter un support spécifique à chaque fois que des registres apparaissent. (Bon, il faudrait peut-être régler quelques détails comme laisser la possibilité de faire des sauvegardes partielles et paresseuses si c'est une technique toujours employée.)

Bof quand on est habitué, on a plus peur du tout, on s'en fout complètement. Effectivement je peux concevoir que si on prend le train souvent et qu'on entend ça pour la première fois, ça peut surprendre.

En même temps j'ai la forte sensation qu'absolument tout le monde s'en branle de ces messages, surtout que l'intuition de probablement la majorité des gens est qu'ils auraient s'ils étaient réellement suivis une efficacité opérationnelle proche du néant : n'importe quel apprenti terroriste voulant faire exploser un TGV veillera à bien étiqueter sa valise-bombe par exemple (et pis d'ailleurs même s'il le fait pas il réussira quand même, c'est pas comme si qui que ce soit cherchait à contrôler la présence d'étiquettes...). Même faire péter un truc au milieu d'une gare doit avoir une très forte chance de réussite si la détonation se produit rapidement après le départ du terro.

Donc ces mesures, c'est de l'agitation pour pouvoir dire "oui oui on fait quelque chose" même si personne n'est dupe, un peu comme les patrouilles de militaires en treillis.

Ptet que ça peut dissuader quelques illuminés les plus débiles néanmoins, auquel cas pourquoi pas.

C'était pas aussi le but du détournement de l'avion d'air france en 1994 ?

ABI est un terme générique que l'on emploie dès que l'on parle d'un sujet qui a un impact sur une compatibilité binaire. Quelques soient les binaires en question. Savoir précisément de quoi on parle quand on dit "ABI" nécessite donc de prendre en compte le contexte. Pour avoir lu tout le thread d'origine, je suis à 200% certain que l'ABI dont il est question ici est l'interface kernel user, avant tout les syscalls, mais il a été aussi évoqué des adaptations dans /sys dépendant de l'architecture, donc l'ABI dont on parle est bien celle complète de la définition classiquement utilisée par les kernel hackers parlant d'interface kernel user.

Vous ne parlez pas de la même ABI.

Il n'y a pas de stabilité de l'ABI interne de Linux.

L'ABI dont on parle ici est l'ABI kernel user. Ça aurait du être évident vu le contexte.

C'est une vision partielle des choses. Certaines vielles ABI moisies sont graduellement dépréciées et supprimées de Linux ou modifiées pour quelque chose de meilleur. Les syscall restent là, et évidemment les passages de params sont gravés dans le marbre une fois pour toute au début, mais ce qu'il y a dans /proc ou /sys ou /dev (etc) fait aussi partie de l'ABI et peut doucement bouger, même si la règle est effectivement de garder de la retrocompatibilité à moyen/long terme même pour tout ça.

La manière dont github est utilisé dans ce cas là ne pose aucun problème. Rien n'a changé dans les méthodes de développements, juste une adresse. Il n'y a aucune dépendance engendrée, et Linus pourra se passer de github pour l’hébergement de référence de Linux du jour au lendemain, ce qu'il compte faire.

ahlala, que de bon souvenirs : sb 16 traditionnelle (surtout pas de pnp toute pourrie et paradoxalement super dûr à configurer) : io 220, irq 5, dma 1 (16-bits), dma 5 (8-bits) (ou l'inverse pour les deux dernier, je sais plus)

Tout est en français, mais là il y a écrit librairie au lieu de bibliothèque.

Bouh !

Si tous les mainteneurs font correctement leur travail et sont attentifs au moment où ils tirent/poussent il ne peut pas y avoir de problème. L'attaquant ne peut pas non plus tenter d'injecter des backdoor en masse pour tomber par chance sur un mainteneur étourdit, donc soit l'attaquant à besoin d'une chance immense, soit il devrait cibler un mainteneur particulier qu'il connait comme étant particulièrement tête en l'air (ce qui est une hypothèse originale mais peu probable)

De plus j'imagine que pas mal de monde va faire le parano et review les commits qui se sont produits aux alentours de cette période. (Quoique la déclaration "tout est safe" pourrait démotiver les gens de faire ce travail...)

Le compromission d'une workstation d'un kernel hacker serait sans doute un moyen beaucoup plus efficace pour injecter discrètement du code malicieux, mais encore faudrait-il que la faille soit très discrète et passe des revues sans que personne ne bronche.

Les grandes sociétés qui se font hacker déclenchent un scandale lorsque les dommages réels et augmentation des risques sont importants pour les tiers, e.g. diffusion de millions de numéros de carte de crédits -- interruption d'un service pendant une éternité.

Ici tout le monde est d'accord pour dire que le problème n'est pas à prendre à la légère, mais que l'hypothèse de la compromission du noyau officiel peut être très très très très très très très probablement écartée.

Il n'y a pas de scandale à avoir. Il y a des réparations à faire, et la sécurité à encore plus renforcer. A lire le communiqué sur kernel.org, le sérieux est déjà extrême dans ce domaine, et je suis près à parier qu'il n'y aura pas non plus besoin d'une interruption de service pendant 1 mois (et même en faisant l'hypothèse absurde qu'il y ait besoin d'en avoir une, les outils sont suffisamment puissants pour que ça soit très peu gênant).

En gros tu veux la disparition des marques, et tu cites certains cas où tu te réjouirais (et beaucoup de monde avec toi) si les marques disparaissaient.

Très bien, maintenant il ne te reste plus qu'à trouver des exemples pour lesquels la disparition des marques aurait un effet clairement néfaste pour le plus grand nombre. Tu réviseras ptet ton jugement quand t'en auras trouvé...

un clavier usb peut préciser sa keymap (param HID bCountryCode)

je ne sais pas si des OS utilisent cette info, et si oui je ne sais pas si on peut désactiver l'utilisation de cette info sur de tels OS

au mieux sur une autre planète ?

Il permet en autres de réaliser de tests de pénétration, ethical hacking, administration de système et de réseau, recherches légales, récupération de données, et caetera.

Y a des DRM qui empêchent d'utiliser la distro de manière offensive ? :p

à part ça, extrait du site :

Matriux est un phénomène qui attendait pour se produire.

Pour faire du marketing à deux balles, même des filles nues auraient été plus efficaces que cette phrase toute pourrie.

Comme ton explication sur l'avantage de grapiller des perfs laisse déjà sous-entendre, les UUOC c'est mal uniquement lorsqu'on doit les passer à l'échelle et que le traitement est bien déterminé et figé. Si c'est du one shot, les UUOC (si on veut couper les cheuveux en 4, en fait certains cas prétendus comme étant des UUOC par certaines personnes) ne sont souvent en fait pas du tout U, car ils permettent de modifier la ligne de commande du pipeline plus rapidement (le fichier d'entrée est isolé au début et ne change pas si l'on remplace toute la fin de la ligne, donc y compris si l'on change la commande à appliquer sur le fichier).

(ya ptet dans certains shells moyen de faire une dérivation de stdin avec le nom de fichier en début de ligne, mais je préfère me contenter de cat que tout le monde connaît déjà et qui permet d'avoir une syntaxe de la commande ne dépendant pas du shell utilisé, quitte à consommer 100 mW.s supplémentaire et à attendre 3 ms de plus).

La notion de compromis vitesse de développement / performance est très classique. Certes dans certains cas on peut acquérir des réflexes qui permettent de faire tout aussi facilement la même chose en atteignant une efficacité absolue, mais ce n'est pas toujours le cas. Sinon on développerait sur x86 tout en langage machine :P (le langage d'assemblage ne permettant pas facilement de repérer des optimisations conviviales telles que le saut en plein milieu d'une intruction pour en obtenir une autre qui fait quelque chose qui n'a rien à voir, et autres joyeusetés). Et on ne ferait certainement jamais rien en shell, pour commencer.

on peut les chaîner, mais je me demande si rambus n'a pas breveté le concept

Pour 99% des logiciels privateurs une cible uniquement 32-bits est amplement suffisante.
Au sein du 1% qui reste, 95% est probablement du logiciel spécifique/pro/whatever et l'utilisateur soit aura de toutes façon les compétences, soit se démerdera car il a quelqu'un qui les a a disposition. Pour le 0.05% restant final, OSEF, utilisez windows si ça semble résoudre vos problème, c'est un OS techniquement tout à fait acceptable aujourd'hui, et si le but est de faire tourner du logiciel privateur alors ça serait bien plus conforme à la thématique.

S'il te faut 24h pour télécharger la moitié de la FNAC dans ta cave avec la première connexion ADSL venue, et que ça pose un problème à quiconque, ce n'est pas tant qu'on est passé à un stade industriel de contrefaçon mais plutôt qu'une certaine "industrie du divertissement" n'a pas su évoluer et est donc devenue relativement à l'époque moderne représentative du moyen âge, ou peut-être même de l'antiquité.

Et tant que j'y suis, désolé Sufflope tu va prendres pour tous les autres, l'esperanto n'est pas une lange non ambiguë, donc je vois pas ce qu'elle vient foutre là. Tu voulais ptet dire Lojban. Comme en plus ce ne sont pas des langues que j'utilise dans ma cave, je ne vois encore moins bien ce que ça vient faire ici.

d'habitude je suis pas du genre à me formaliser à être moinssé, surtout quand je trolle sur des sujets polémiques (ce qui n'est pas le cas ici, puisqu'on peut difficilement prétendre qu'un sujet mathématique, formel, de complexité algorithmique, soit polémique... c'est plutôt dans ce cas qu'il y a des gens qui y comprenne quelque chose, et d'autres moins -- ce qui n'empêche pas ces derniers de penser qu'ils y comprennent beaucoup de choses)

mais là j'aimerai bien que messieurs les moinseurs aillent apprendre suffisamment au sujet de la complexité algorithmique avant de se déchaîner, pcq connaitre juste le mot NP parce que vous avez lu wikipedia et croire que c'est magique, c'est de la connerie, de l'idiotie, tout ce que vous voulez

donc PUTAIN, du fond de ma cave : (oui oui je suis énervé, j'écris des gros mots et tout) je reformule mon message qui a du mal passé, et être compris comme "un cerveau c'est comme un microprocesseur" par des gens qui devraient apprendre à lire , ce que ceux qui SAVENT lire peuvent constater trivialement qu'il ne voulait pas dire ça du tout -- bref reformulation de mon message pour les abrutis : c'est pas parce qu'un problème est NP-complet qu'un être humain peut le résoudre dans le cas général tandis qu'un ordinateur ne peut pas. Croire le contraire, c'est faire preuve d'une confusion mentale que je ne peux même pas commencer à comprendre -- c'est avoir juste assez de connaissance en complexité algorithmique (pour être très clair vu le niveau auquel je m'adresse : très peu) pour être dangereux.

sur ce, déchaînez vous