Vous n'êtes pas identifié(e).
Sur le terrain de la confiance ou la méfiance ce n'est pas faux, mais ce n'est pas mon propos. C'est juste une question de respect des droits et libertés de l'utilisateur.
Alors quel est ton propos au juste ? Je ne vois pas le rapport entre microcode et respect des droits et libertés de l'utilisateur.
D'une façons ou d'une autre il faut bien vérifier l'information fournis par l'utilisateur, la lecture en découle c' est à dire:
la lecture du fichier ou est stoquer le mots de passe
Les mots de passe des comptes utilisateurs ne sont pas stockés en clair dans le fichier /etc/password ou /etc/shadow, ils sont "hachés" de façon non réversible. Il n'est pas impossible de retrouver un mot de passe à partir d'un hachage (cf. le programme "john the ripper") mais c'est très long s'il est robuste. Le seul moment où le mot de passe d'un utilisateur va être présent en clair dans la mémoire, c'est lorsque l'utilisateur le tape. J'ose espérer que les programmes qui manipulent ce mot de passe ne le stockent que le temps strictement nécessaire à sa vérification.
Il vaut mieux montrer que raconter.
Hors ligne
Philou92 a écrit :Je ne vois pas le rapport entre microcode et respect des droits et libertés de l'utilisateur.
Le paquet intel-microcode n'est pas libre.
Les libertés auxquelles je fais allusion sont là : https://www.gnu.org/philosophy/free-sw.html.
L'assimilation d'un logiciel non libre à un malware est évoquée là : https://www.gnu.org/proprietary/proprietary.html
La nouvelle faille de sécurité mds est assimilable à un vice caché. Intel offre comme dédommagement que deux solutions : la peste et le choléra. Soit laisser la faille telle quelle, ou installer un logiciel non libre qui corrige la faille en dégradant les performances du processeur avec effet a priori irréversible (tu me corriges si je dis une bêtise) .
Cerise sur le gâteau, en installant ce microcode la licence (disclaimer) Intel limite de façon substantielle la garantie : https://github.com/intel/Intel-Linux-Pr … er/license.
Tousse antique Ovide !
Hors ligne
Le paquet intel-microcode n'est pas libre
Pas plus que ne l'est le microcode déjà inclus dans ton processeur Intel. Pourtant jusqu'ici ça ne semble pas t'avoir posé de problème d'utiliser ce processeur avec son microcode non libre.
installer un logiciel non libre qui corrige la faille en dégradant les performances du processeur avec effet a priori irréversible
Il y a déjà un logiciel non libre dans ton processeur. Installer le paquet intel-microcode ne fera que le remplacer.
Non, ce n'est pas irréversible. Le microcode est en mémoire volatile et doit être rechargé à chaque démarrage.
Cerise sur le gâteau, en installant ce microcode la licence (disclaimer) Intel limite de façon substantielle la garantie
Clause habituelle de n'importe quelle licence de n'importe quel logiciel.
Il vaut mieux montrer que raconter.
Hors ligne
La sagesse ne peut pas entrer dans un esprit méchant, et science sans conscience n'est que ruine de l'âme
Faisons le pari qu'un jour Intel fera preuve de plus de sagesse.
Le microcode est en mémoire volatile et doit être rechargé à chaque démarrage.
OK, merci pour l'info.
Tousse antique Ovide !
Hors ligne
science sans conscience n'est que ruine de l'âme...
Hors ligne
on optimise pas
Au contraire, toutes ces failles affectant l'exécution spéculative résultent d'optimisations.
Il vaut mieux montrer que raconter.
Hors ligne
d33p a écrit :on optimise pas
Au contraire, toutes ces failles affectant l'exécution spéculative résultent d'optimisations.
Bonjour,
je pense que d33p parlait d'optimiser l'existant, en le rendant plus sécurisé.
Acer Aspire 5733 - Debian 12 Xfce
Hors ligne
Etant dyslexique, j'ai des problèmes quant à la rédaction de messages en français courant. Je vous prie dès lors d'accepter toutes mes excuses si mes interventions peuvent vous paraître étranges et je vous remercie d'avance pour votre compréhension.
Hors ligne
science sans conscience n'est que ruine de l'âme...
Hors ligne
“It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is.” - Bruce Lee (philosophe)
Hors ligne
A priori la seule solution qui semble valable va être d'utiliser du matériel entièrement libre type olimexx ou thinkpad compatible libreboot.
Mauvais exemples. Les cartes Olimex ne sont pas entièrement libres puisqu'elles utilisent des processeurs d'architecture ARM, qui ne sont pas libres. Etant donné que certains types de processeurs ARM sont aussi affectés par des failles d'exécution spéculative, ça ne résoud rien. Quant au Thinkpad, ce n'est pas du matériel libre du tout, même avec un firmware libre.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par naguam (09-06-2019 16:39:14)
Unixien?
Compiler son kernel!
Hors ligne
pourquoi linux ne supporte pas amd ? :x
Qu'est ce tu racontes? Tu sais bien que j'ai un PC full amd (cpu et gpu) et que ça fonctionne très bien.
Toi même tu parlais d'investir dans un Ryzen.
D'ou vient ce retournement?
A computer is like air conditioning - it becomes useless when you open Windows (L.T)
Et Aussi : PC5: AMD Ryzen 5 3500X @4.1Ghz | CG: Nvidia GTX 970 |RAM : 8MB | OS: debian 11 KDE 5.20.5 | K : 5.10
Hors ligne
le matériel libre n'existe pas.
tout matériel a besoin d'un firmware pour fonctionner. ( sans micro logiciel le marériel n'a aucune utilité , ceci dans tous les domaines , de la machine a laver a l'ordinateur ).
Tu mélanges des notions distinctes. Par exemple je te garantis que mon four électrique et ma cuisinière à gaz n'ont besoin d'aucun firmware pour fonctionner. D'autre part un firmware n'est pas forcément propriétaire, il existe des firmwares libres comme coreboot ou libreboot.
le matériel nous appartient
Mais pas son design, c'est ce qui fait qu'il n'est pas libre indépendamment des firmwares qu'il est susceptible contenir.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par naguam (10-06-2019 11:39:55)
Unixien?
Compiler son kernel!
Hors ligne