L'UEFI, « interface micrologicielle extensible unifiée » est un sujet sur lequel LinuxFr.org vous informe régulièrement. Un nouvel épisode dans la mise en place progressive sur certains matériels de cette solution, accompagné de son « secure boot » mérite qu'on s'y attarde à nouveau un peu. Et ceci de manière factuelle.
UEFI et secure boot
UEFI et secure boot ne seront pas désactivables sur les matériels de type ARM pré-installés avec Microsoft Windows. Bien que posant des problèmes éthiques aux consommateurs, cela restera probablement anectodique dans la mesure où cela ne concerne que les smartphones et tablettes Windows : soit une part de marché faible, et même avec un essor potentiel des tablettes Windows, ne concernera au final des matériels qui ont été spécifiquement prévus pour ce système. Faire booter un autre système dessus, même sans uefi, ne constituera probablement pas un intérêt majeur, ni pour les industriels ni pour les hackeurs ni pour le consommateur.
Néanmoins il faudra rester vigilants afin que si la situation de présence sur ce marché évoluait, celle concernant uefi évolue aussi.
Microsoft
Microsoft a par contre autorisé la désactivation du « secure boot », et la mise en place de clefs spécifiques à l'utilisateur, pour les plates-formes de type Intel. Ce n'est certainement pas philanthropique, mais a peut être un rapport avec un potentiel problème d'abus de position dominante si cette option n'avait pas été retirée.
Fedora 18
Fedora 18 prendra en charge a priori le couple UEFI & secure boot sur plate-forme Intel. Ce type d'outils est toujours à double tranchant : d'un côté il apporte des possibilités intéressantes en termes de sécurité, mais d'un autre il peut devenir une arme anticoncurrentielle. En tout cas, il s'agit d'un casse-tête pour l'utilisateur final. Fedora fait donc le choix a priori de prendre en charge cette combinaison, et un article de Matthew Garrett, développeur noyau chez Redhat, fait le point sur la situation actuelle.
Aller plus loin
- Journal : Ta Fedora sera signée par Microsoft (567 clics)
- UEFI sur Wikipedia (248 clics)
- Matthew Garrett fait le point sur la situation actuelle pour Fedora (104 clics)
# Pas intéressant ?
Posté par Xaapyks . Évalué à 10.
Et pourquoi pas ?
[^] # Re: Pas intéressant ?
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Je m'étonne aussi !
Et pourquoi ça changerait tout si la tablette tournait sur un proco intel ?
Je comprends ces affirmations de cette manière là :
Intel déverrouillable
Cause : Intel est un intérêt majeur, pour les industriels et pour les hackeurs et pour le consommateur
ARM pas déverrouillable
Cause : ARM n'est pas un intérêt majeur, ni pour les industriels ni pour les hackeurs ni pour le consommateur
Je ne suis pas sûr que la dernière affirmation soit pertinente.
L'intérêt d'une plateforme, c'est de booter un système dessus, le mot "autre" est de trop, le concept d' "autre" est humain, philosophique.
Pour une machine de Turing, ça n'a pas de sens.
Lu comme ça :
On se demande à quoi ça sert !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas intéressant ?
Posté par NanoTech . Évalué à 1.
Actuellement les tablettes ARM ne sont pas très bien supportées par le mainline kernel (même si la situation s'améliore rapidement), et si on veut faire tourner GNU/Linux sur ce genre de machines, on doit bien souvent prendre les pilotes (malheureusement souvent binaires ou de très mauvaise qualité) développés pour Android par un OEM.
Donc actuellement les machines ARM sur lesquelles on a des chances d'arriver à booter GNU/Linux avec un support matériel correct sont des machines existant en version Android.
Il est évident qu'à long terme, les pilotes seront écrits ou portés à GNU/Linux pour un peu toutes les machines, y compris celles n'ayant qu'une version Windows 8. Là, cette pratique anti-concurrentielle va devoir être contournée par du jailbreaking hardware.
Si jamais Windows 8 se met à représenter une part non négligeable du marché, j'espère, sans trop y croire, qu'on va faire agir une loi anti-trust pour lui interdire ce genre de pratique déloyale.
[^] # Re: Pas intéressant ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Ce n'est pas seulement une question de pilote. Je vous rappelle qu'ARM n'est pas une plate-forme standard comme le PC à la IBM, mais seulement un jeu d'instructions de processeur. En particulier, il n'existe pas de moyen standard de démarrer un ordinateur à base d'ARM, ni d'énumérer son matériel.
En pratique, cela signifie que chaque système d'exploitation doit être spécifiquement adapté pour chaque modèle à prendre en charge. Que pour chaque nouveau modèle, il faut effectuer un travail de portage spécifique du noyau, de l'installateur et du système d'amorçage.
Avoir des pilotes systématiquement intégrés au noyau Linux serait une bonne chose, mais ça ne suffira pas à régler le problème. En particulier, les distributions GNU/Linux usuelles ne pourront jamais s'installer et fonctionner simplement sur plus d'une poignée de modèles.
[^] # Re: Pas intéressant ?
Posté par NanoTech . Évalué à 8. Dernière modification le 06 juin 2012 à 13:20.
Les choses peuvent changer.
Microsoft va améliorer la standardisation des machines ARM, grace à UEFI et ACPI, qui va permettre de démarrer un noyau de manière standardisée ainsi que l'énumération des périphériques et l'attribution de leur ressources matérielles (IRQ, DMA).
Je crois que grâce à ça, Microsoft n'aura pas à distribuer le code source de Windows 8 (contrairement à Windows CE), comme pour les Windows sur x86.
C'est vraiment dommage:
1) On standardise, permettant la liberté d'installation et de configuration.
2) On verrouille.
Références:
http://arstechnica.com/information-technology/2012/02/windows-8-on-arm-building-a-common-windows-platform/
http://lkml.org/lkml/2011/10/16/3
[^] # Re: Pas intéressant ?
Posté par Maclag . Évalué à 10.
À une époque, et encore aujourd'hui, des efforts considérables avaient été faits pour avoir des Linux qui tournent bien sur le matériel Apple.
Or, on ne peut pas vraiment dire que le matos Apple ait été pensé pour autre chose que les OS Apple, ni qu'ils représentent une part dominante du marché.
Dois-je en conclure que Linux sur Mac, c'est "pas intéressant"?
Ce serait d'autant plus étrange qu'Apple est l'un des rares qui ne faisait pas de chichi pour rembourser l'OS depuis le début (bon, ils le remboursaient une broutille, mais l'idée, au moins était là…).
Alors que les archis ARM auraient dû être l'occasion rêvée de remettre un peu les choses à plat, on va au contraire profiter de leur arrivée pour préparer une excuse "historique":
"à l'époque du verrouillage, MS avait une faible part de marché, tout le monde s'en foutait, vous n'allez pas chouiner maintenant sous prétexte qu'ils ont du succès, non??"
Il est vrai que les archis ARM auraient grand besoin d'une standardisation. Elle profiterait à tout le monde…
ah ben non! La standardisation tant souhaitait est sur le point d'être forcée par MS, et ne concernera donc pas les autres OS, mais "c'est pas grave: MS c'est pas une grosse part de marché.
Conclusion: Dans quelques années, il y aura d'un côté les systèmes Windows 8: l'OS est prêt quasi en même temps que le prototype, et tous les autres: un Android par appareil, et un projet de "Linux sur [insérer ici modèle et version de l'appareil]" qui mettra 2 ans à aboutir par ingénierie inverse, juste le temps que le modèle soit considéré obsolète…
[^] # Re: Pas intéressant ?
Posté par Albert_ . Évalué à 5.
Surtout que le paragraphe peut tout a fait correspondre au PC vu que ceux ci sont fait, en grande majorite pour faire tourner Windows par l'inverse a l'inverse de linux qui lui est adapté au materiel sur lequel il tourne.
Je sais que l'on va m'attaquer sur les affirmations des PC fait pour windows mais bon il suffit de voir les normes non respecte par windows que linux est oblige d'implementer pour s'apercevoir que c'est vrai. Comme la pseudo-norme ACPI et je peux redonner le lien de Bill Gates si il faut vraiment :).
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -9.
Encore une connerie.
Prouve moi que Windows ne respecte pas ACPI.
[^] # Re: Pas intéressant ?
Posté par mosfet . Évalué à 7.
En fait c'est un peu plus subtil que çà, le problème avec ACPI est qu'il est implémenté au niveau du bios bien souvent de manière erronée et que du coup l'OS peut ou non surchargé certaines tables. Je parle de çà car j'ai pas mal joué avec des hackintosh et bidouiller la gestion de l'ACPI est une des taches les plus importantes pour avoir un système qui fonctionne. Maintenant je ne suis pas un expert non plus et si quelqu'un peut confirmer je me sentirais moins seul. Tout ça pour dire que l'OS n'est pas forcement en cause mais plutôt le BIOS au dessous.
[^] # Re: Pas intéressant ?
Posté par Alex . Évalué à 6.
la tournure est mal faite
les constructeurs ne ne respectent pas la norme, ou fournissent des composants bugguer, ils compensent en fournissant des divers fonctionnels spécifiques qui corrigent ces différents problèmes.
[^] # Re: Pas intéressant ?
Posté par Albert_ . Évalué à 3.
http://www.osnews.com/story/17689/Bill_Gates_on_Making_ACPI_Not_Work_with_Linux
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -10.
Je t'ai pas demande la copie d'un e-mail contenant une idee sur le protocole lui-meme dont tu ne sais meme pas si l'e-mail a ete suivi d'effets, je t'ai demande une PREUVE que l'OS Windows ne respecte pas la norme ACPI.
Donne moi les donnees techniques permettant a chacun ici d'essayer et voir que Windows viole la norme.
[^] # Re: Pas intéressant ?
Posté par oinkoink_daotter . Évalué à 7.
L'OS, c'est dur à prouver. Par contre, votre compilo AML pourrait être plus strict… Le compilo intel fait bien la tronche quand il doit décompiler/recompiler l'Œuvre d'un OEM. M'enfin, j'ai pas l'impression qu'il y ait de suite de compliance fournie par l'UEFI forum.
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -10.
Tout a fait, mais ca c'est normal car le compilo de MS il est fait pour gerer un OS specifique, le compilo d'Intel il est fait pour une cible bien plus large.
[^] # Re: Pas intéressant ?
Posté par oinkoink_daotter . Évalué à 9.
La, je ne suis pas d'accord: votre compilo devrait être prévu pour générer un truc ACPI compliant, pas juste de l'ACPI qui contente l’interpréteur ACPI Microsoft (une implémentation de fonction qui ne prend pas les paramètres définis dans le prototype, qui ne renvoie rien ou qqch qui n'est pas du type attendu sans faire sourciller le compilo, c'est vraiment génant).
Sinon, d'Aucuns pourrait penser que c'est sciemment fait pour faire des BIOS qui ne marchent qu'avec votre interpréteur.
Ce qui vous sauve, c'est qu'on ne sait toujours pas ce que ça fumait chez intel le jour quand ils ont pondu Ça, en oubliant les test de compliance en cadeau bonux :)
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -10.
Pourquoi donc est-ce que notre compilo devrait etre prevu pour d'autres OS ?
Ce compilo n'a absolument jamais ete prevu pour etre utilise dans d'autres cas, on n'est pas des contractants pour Redhat, freeBSD, et autres et faire du boulot dont Windows n'a pas besoin quand le seul but est de supporter Windows, et il faudrait etre sacrement stupide pour croire le contraire.
Les constructeurs qui veulent du support multi-OS, ils savent tres tres bien quel compilo prendre, car Windows marche sans aucun probleme avec ce qu'emet le compilo d'Intel. Si ils ne le font pas, il faut leur demander pourquoi.
[^] # Re: Pas intéressant ?
Posté par oinkoink_daotter . Évalué à 10.
Ben parce qu'ACPI est un standard. Du coup générer un truc standard, ça devrait être l'objectif. C'est un peu comme si un compilo java sortait du code qui ressemblait de loin à du java et que son éditeur disait "ah oui, mais compilo java il fait des trucs tout chelou, mais vous comprenez il n'est fait que pour notre JVM".
(oui, je sais cet exemple est mal choisi, mais c'est le seul qui me vienne à l'esprit et il est tard, la)
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -4.
Ben oui l'exemple est mal choisi, parce que deja le compilo genere du code standard quand tu ne fais pas l'idiot, et qu'ensuite je t'invite a lire les commentaires ici :
http://www.osnews.com/thread?230525
mjg59 ecrit :
Since then, Windows has ended up more spec-compliant and ACPI tables have got more compatible. It'd be nice to blame Linux's ACPI problems on Microsoft, but the fact remains that most of the problems we've hit in power management have been bugs in the Linux kernel - things like not reprogramming hardware correctly when resuming, executing ACPI methods in the wrong order, not executing some ACPI methods at all, hardware vendors not documenting their own deviations from the specification, that sort of thing. Like I said, this stuff is hard, and people have only really started working on it in the last couple of years.
Et qui est mjg59 ? C'est Matthew Garrett, un des dev kernel pour ACPI !
[^] # Re: Pas intéressant ?
Posté par claudex . Évalué à 5.
Oh, un article de 2007 pour justifier les problèmes de 2012.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -3.
Quels problemes de 2012 ? Tu me montres un seul element qui tendrait a dire que Windows a empire niveau ACPI depuis 2007 ?
[^] # Re: Pas intéressant ?
Posté par Guillaume Knispel . Évalué à 4.
Toute la stratégie de MS dévoilée subrepticement au grand jour. C'est beau. Et machiavélique.
[^] # Re: Pas intéressant ?
Posté par khivapia . Évalué à 5.
Pourquoi donc est-ce que notre compilo devrait etre prevu pour d'autres OS ?
Parce que le binaire compilé est intégré à du matériel (BIOS, firmware UEFI), pas à du logiciel. Et que le matériel peut être utilisé par d'autres OS.
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -7.
On le sait tous ca, mais de nouveau, c'est pas notre job de s'occuper de ca, c'est celui des OEMs, c'est leur matos.
Nous on s'occupe de leur faciliter la vie pour gerer notre OS, si ils ne font pas de grosses conneries notre compilo emet du code standard supporte par les autres OS, le compilo n'est pas une pourriture.
Mais c'est pas notre boulot de fignoler ce compilo plus que necessaire pour notre OS, les OEMs qui veulent s'assurer que d'autres OS tournent sur leurs materiel ont d'autres compilos disponibles, qui fonctionnent sans probleme avec Windows, et ils savent tres bien quel compilo fait quoi.
[^] # Re: Pas intéressant ?
Posté par khivapia . Évalué à 7.
c'est pas notre boulot de fignoler ce compilo plus que necessaire pour notre OS
Bref vous ne rendez pas de service aux fabricants de matériel : le métier d'un éditeur de compilateur de table ACPI est de fournir un compilateur de table ACPI qui puisse tourner sur le matériel en respectant la norme, la norme étant justement là pour rendre la gestion du matériel indépendante de l'OS, de la même façon que compatible IBM PC.
Votre compilateur n'est pas fait pour fournir un binaire qui tourne sur un matériel, mais pour qu'il tourne sur un matériel sur lequel est installé windows.
Du coup ce n'est pas un compilateur pour table ACPI, c'est un compilateur pour table utilisée par windows. C'est très différent.
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -10.
Le compilo respecte la norme, il ne met pas de warnings pour tous les cas d'erreurs car l'OS n'a pas besoin de gerer ces cas la et donc on s'en fout.
Votre compilateur n'est pas fait pour fournir un binaire qui tourne sur un matériel, mais pour qu'il tourne sur un matériel sur lequel est installé windows.
C'est evident, on est un editeur d'OS, et l'OS s'appelle Windows. Notre job c'est d'aider les OEMs a supporter Windows, pas les autres OS. On ne vas pas entuber les autres OS volontairement, mais on ne va pas non plus se casser la tete pour s'assurer qu'ils sont geres parfaitement dans tous les cas imaginables.
Du coup ce n'est pas un compilateur pour table ACPI, c'est un compilateur pour table utilisée par windows. C'est très différent.
C'est faux, notre compilo genere de l'ACPI standard, il ne detecte simplement pas certains types d'erreurs car ces types d'erreurs sont sans effet sur Windows.
[^] # Re: Pas intéressant ?
Posté par napster2core . Évalué à 3.
Prouve moi que Windows suit la norme, et prouve le moi comme tu veux qu'on te prouve que Windows ne la suit pas, avec explications techniques et tout et tout.
Bonne chance :D
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Pas intéressant ?
Posté par Albert_ . Évalué à 5. Dernière modification le 06 juin 2012 à 17:00.
Je ne devrais meme pas me fatiguer a repondre tellement il a ete prouve que Microsoft ne respecte pas la norme ACPI et pour une seule raison: celle d'empecher Linux de fonctionner correctement (comme le prouve l'email de leur ancien PDG).
Juste pour rigoler un tout petit peu:
http://lwn.net/Articles/291498/
The Intel compiler is more strict.
Warnings often lead to general ACPI BIOS errors that may also affect
Microsoft Windows or other operating systems. Some may just point to
ACPI specification violations which the Microsoft compiler allows.
WMI is a Microsoft specific service. A small part of it
describes possible ACPI WMI implementations provided by the BIOS.
This is not part of the official ACPI specification and BIOS developers
should avoid using it.
Maintenant a lui de nous prouver que je dis des conneries. Sa parole ne me suffit pas je veux du lourd comme preuve. Il n'a qu'a poster le code gerant l'ACPI sous windows :D
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -8.
Ton incompetence technique n'a toujours pas change.
Je t'ai demande prouver que l'OS ne respecte pas ACPI. Toi tu me sors le compilo ACPI de MS qui ne met pas certains warnings. Ce compilo est utilise pour les BIOS, il ne genere pas un seul bit qui finit dans l'OS.
Si tu arrives a me montrer ou ce compilo, ou un binaire produit par lui est sur le DVD / CD de Windows je t'offre une Ferrari.
Quand a WMI ce n'est absolument pas specifique a Windows, c'est une implementation du standard WBEM, encore une connerie de plus !
J'attends toujours une preuve que l'OS ne respecte pas ACPI.
[^] # Re: Pas intéressant ?
Posté par Obsidian . Évalué à 5.
'faut se méfier avec ce genre de promesses ! Ça pourrait pousser certains à déployer suffisamment de moyens pour te placer dans une position où tu serais obligé de la tenir. :-)
[^] # Re: Pas intéressant ?
Posté par pasBill pasGates . Évalué à -8.
Moi je ne lance pas d'accusations, je n'ai rien a prouver.
# ARM != mobile
Posté par catwell (site web personnel) . Évalué à 7.
Heu, pas d'accord. Intel se lançant sur le marché mobile, il y a de très fortes chances pour que les fabriquants de puces ARM se lancent sur celui du PC. Qui plus est techniquement ARM a de solides arguments, au moins pour les portables à faible consommation du type Macbook Air.
Cette décision concerne donc bien des terminaux moins mobiles que ceux dont tu parles…
[^] # Re: ARM != mobile
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Je plussoie, mais coté HPC (sur lequel les plateformes ARM commencent à pointer leurs papattes).
On peut monter un o1000 en 24U, pour la conso d'un 32 cores intel…
Alors certes, ce sera sans doute dans des "trucs" dédiés, mais on commence petit, on sait pas comment ça finit… Et UEFI et sécioureboute seront sans doute de la partie, connaissant certains fabricants de matos HPC…
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: ARM != mobile
Posté par steph1978 . Évalué à 3.
en effet ça pointe le bout de son nez
[^] # Re: ARM != mobile
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à -2.
Oué, y'a aussi le projet PierreRouge chez le constructeur à deux lettres qui monte, qui monte…
Bref, ça va arriver dans le HPC.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Custom mode ?
Posté par Ronan Billon . Évalué à 0.
J'ai une question. J'ai lu qu'il existait un mode custom dans le journal en lien. Si ce mode fait parti de la spécification alors, les bidouilleurs/hackers pourront toujours s'en sortir pour booter sur un système quelconque, n'est-ce pas ? Certe, ça limite la propagation des logiciels libre aux personnes motivées.
Ou bien existe-t-il une subtilité que je n'ai pas compris et qui verrouille le système ?
[^] # Re: Custom mode ?
Posté par NanoTech . Évalué à 7.
Pour obternir la certification Microsoft, le support custom mode est obligatoire pour les machines vendues Windows 8 x86 OEM, mais interdit pour les machines Windows 8 ARM.
En gros, je crois que Microsoft s'est dit qu'il aurait forcément un procès au dos s'il faisait ça pour les PC pour lequel il a le monopole, mais qu'il peut se le permettre sur tablette ARM, pour lequel il a une toute petite part du marché.
[^] # Re: Custom mode ?
Posté par Damien Thébault . Évalué à 2.
Pas de Custom Mode sur les uefi ARM compatibles Windows 8.
Le Custom Mode est uniquement disponible pour les uefi x86(-64).
[^] # Re: Custom mode ?
Posté par Ronan Billon . Évalué à 0.
OK,
Je viens de lire sur wikipedia l'historique de ce mode entre ARM et Windows 8. Donc, en décembre 2011 ça devait exister (Section Criticism). Puis en janvier 2012, ça n'existe plus (Hardware Restrictions). Peut être que ça évoluera encore ?
# plate-forme Intel ... et AMD ?
Posté par Mimoza . Évalué à 6.
Faut il comprend "platforme Intel" comme "platforme x86" ? Ou es ce vraiment limité au matos Intel ?
[^] # Re: plate-forme Intel ... et AMD ?
Posté par Tonton Th (Mastodon) . Évalué à 6.
Un itanium dans un smartphone, ça réchauffe bien les oreilles.
[^] # Re: plate-forme Intel ... et AMD ?
Posté par oinkoink_daotter . Évalué à 4.
Faut voir le bon côté des choses : ça ne te les réchauffera pas longtemps :)
Ou alors, c'est que le téléphone embarque une tranche EPR au quel cas en plus d'avoir chaud à l'oreille, tu feras de la lumière vert luisant staïle.
/o\ -> []
# UEFI ca ne se désactive pas
Posté par oinkoink_daotter . Évalué à 2.
Désactiver UEFI ca a autant de sens que désactiver le BIOS. Si par désactiver tu entends "booter en émulation BIOS", ça ne change pas grand chose, car tu utilises toujours l'UEFI au travers d'une émulation fournie par celui-ci.
[^] # Re: UEFI ca ne se désactive pas
Posté par Misc (site web personnel) . Évalué à 5. Dernière modification le 06 juin 2012 à 13:24.
ça ne serait pas la seule erreur dans la dépêche.
Par exemple, c'est une proposition, pas une décision pour le moment. Elle est encore débattue.
De même, se focaliser sur les tablettes Windows , c'est aussi totalement ignorer que c'est déjà le cas pour plein de tablettes autres, et donc que le secureboot n'est que la normalisation d'une tendance de fond déjà existante et déjà sur le marché.
Enfin, c'est pas Microsoft qui a autorisé la désactivation, c'est le groupe UEFI suite aux réclamations de Red Hat, de Ubuntu et sans doute d'autres durant les meetings de mise au point du standard. Et Microsoft a demandé à ce que la désactivation soit possible pour avoir le logo kivabien.
Enfin, il est totalement passé sous la trappe la possibilité d'utiliser ses propres clés. Dans un contexte de certificat volé à Microsoft, ça me semble un point important à rappeler.
# Anecdotique ?
Posté par elboulangero (site web personnel) . Évalué à 6. Dernière modification le 06 juin 2012 à 08:18.
Hmmm, je vais peut-être dire une connerie, mais je me lance. Nokia a décidé récemment d'utiliser Windows Phone comme plate-forme pour tous ses futurs smartphones. Et Nokia, bien qu'en perte de vitesse, c'est toujours un des plus gros vendeur de smartphones au monde.
Donc dire que les parts de marché des smartphones Windows sont faibles et que c'est "anecdotique", c'est vrai pour aujourd'hui, OK. Mais si Nokia arrive à se remettre dans la course, demain ça changera complètement la donne.
Après je maîtrise pas le sujet à fond, peut-être qu'UEFI n'est pas installé sur ces smartphones Nokia, va savoir. Corrigez moi si je me trompe.
Je vous mets quelques liens pour ceux que ca intéresse:
http://www.eco-conscient.com/art-714-quels-sont-les-parts-de-marche-des-fabricants-de-smartphone-apple-rim-htc-samsung-nokia.html
http://www.lepoint.fr/high-tech-internet/windows-phone-nokia-lance-ses-nouveaux-smartphones-26-10-2011-1389310_47.php
Pour moi la situation n'a rien d'anecdotique en tout cas. Si Microsoft prend la peine de faire tout ce bordel avec UEFI, c'est bien qu'il a l'intention de devenir un gros acteur sur ARM. Et donc, dire que c'est pas grave parce qu'aujourd'hui ça ne concerne que peu d'appareils, sans regarder à demain, c'est vraiment donner le bâton pour se faire battre.
[^] # Re: Anecdotique ?
Posté par steph1978 . Évalué à 3.
avec des si…
[^] # Re: Anecdotique ?
Posté par zebra3 . Évalué à 5.
… on coupe du bois ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Complément
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Position plus officielle, de Redhat : «"Microsoft will provide keys for Windows, Red Hat will provide keys for Red Hat Enterprise Linux and Fedora, (…)»
[^] # Re: Complément
Posté par Zenitram (site web personnel) . Évalué à 6.
Pas tout suivi : les 99$, on les file à Verisign, OK, mais notre clé, elle va comme "sous-clé" de Microsoft ou directement dans l'UEFI de la machine?
Bref, quelles clés contiendra l'UEFI? J'ai l'impression que pour le moment seulement la clé Microsoft, et que c'est Microsoft qui "validera" les autres clés à 99$… Je vois mal l'UEFI se mettre à jour avec de nouvelles clés tous les jours (pour quand je paye moi mes 99$). Ou Microsoft + RedHat, mais du coup Debian est baisé.
bref, pas clair du tout!
[^] # Re: Complément
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 1.
Si j'ai bien compris, une fois les 99$ payés, tu peux uploader un binaire sur un site Microsoft, et tu récupères un binaire signé avec la clé Microsoft quelque temps plus tard.
L'idée pour Fedora/Redhat est de faire signer un bootloader simplifié capable de vérifier et de lancer un GRUB 2 signé avec une clé Fedora/Redhat.
Si Debian ou Ubuntu ou Arch ou d'autres veulent faire la même chose, il leur en coûtera 99$ à eux aussi.
[^] # Re: Complément
Posté par Zenitram (site web personnel) . Évalué à 4.
Et donc RedHat (et Debian, et…) dépendent de la clé Microsoft.
«"Microsoft will provide keys for Windows, Red Hat will provide keys for Red Hat Enterprise Linux and Fedora, (…)» ma parait alors des plus boiteux, en faisant croire qu'ils sont à égalité, alors que Red Hat sera dépendant de la clé Microsoft (et donc Microsoft peut révoquer ou refuser de signer une mise à jour à tout moment, l'inverse n'étant pas vrai).
Bon, reste que ce sera sans doute très mal vu si Microsoft fait ça, donc c'est la moins pire des solutions. Dommage que Red Hat n'ai pas ajouté la sienne de clé dans les UEFI pour être à égalité… Sans doute pas assez intéressant financièrement pour lui.
Corrigez si je me trompe.
[^] # Re: Complément
Posté par Albert_ . Évalué à 3.
Moi j'ai surtout l'impression que l'on retourne 40 ans en arriere ou chaque machine vendu aura son propre systeme et que rien ne sera compatible entre. Il sera impossible de faire un update sans payer voir pire vu que tu seras tenu par les parties sensibles tu seras forces de prendre un "contrat de maintenance" si tu veux avoir des mises a jour de securite et comme tu ne pourras pas installer un autre systeme tu n'auras que tes yeux pour pleurer le bon temps.
[^] # Re: Complément
Posté par bubar🦥 (Mastodon) . Évalué à 1. Dernière modification le 06 juin 2012 à 15:43.
Tu ne te trompes pas, si on reste dans le cadre de l'usage «michue», car sur plateforme Intel in sera possible de fournir peut être ses propres clefs de signatures (ou de désactiver le SecureBoot, mais cela serait dommage vu qu'il s'agit d'un bel outil, s'il est bien utilisé) La question ne se posant alors que pour une «installation par défaut» sans devoir rien faire d'autre que placer une galette. Peut être que d'ici là les installeurs seront mis à jour pour demander une telle clef, personnelle. Ce qui, même dans ce cas, demandera des manipulations rendant quelques peu caduques les efforts pour simplifier l'installation d'un Linux.
Corrigez moi si je me trompe aussi ;-)
ps : j'en profite pour signaler que cette dépêche est totalement incomplète, elle ne devait pas être publier en l'état : il s'agissait d'une introduction proposée, afin d'être augmenter. L'objectif était de faire moins trolliphère et plus factuel que mon précédent journal. (j'attendais donc voir si d'autres personnes y participaient, surtout ceux nous ayant fait des journaux et dépêches détaillées sur le sujet). Hier matin, en voyant «en modération» au moment de la reprendre [ajoutez des précisions et traductions, corrigez des imprécisions) me suis «chouette, ça a pris», mais … surprise au moment de lire la publication. Il y a eu un malentendu ce week end, sa non-évolution menant à une publication.
[^] # Re: Complément
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Bien sûr, il aurait été intéressant de faire un article plus complet, plus détaillé, plus documenté… Pour quel niveau de précision ? Cela aurait pris combien de temps ?
Un article même trollifère, recueille de nombreux avis concrétisés par de nombreux commentaires. Finalement, la somme de toutes ces réflexions constitue un article de référence.
C'est cela qui fait l'originalité et la force de Linuxfr.
[^] # Re: Complément
Posté par duf . Évalué à 3.
De ce que j'en comprends aussi, ça signifie que tous les mecs qui se font leurs propres distributions (pour de la musique, dédié à de la vidéo, pour un serveur, un htpc, etc.) ils seront "baisés" et devront passer par des grosses distributions commerciales ou communautaires qui auront les moyens de payer les 99$… ou sinon ils devront s'acquitter des 99$ à symantec(verisign) ?
Si j'ai bien compris (c'est tellement fumeux que j'ai pu comprendre à l'envers) alors je trouve ça scandaleux !
[^] # Re: Complément
Posté par Zenitram (site web personnel) . Évalué à 2.
Après, c'est que $99 pour avoir des non-geeks (les geeks pouvant décocher la case dans UEFI) utiliser ton produit…
Je vais te faire peur : je paye déjà $99 pour avoir un affichage bleu "sécurité" à la place du jaune "non sécurité" sous Windows (ça fait plaisir à certaines entreprise de pouvoir vérifier ma signature, et un jour Microsoft changera bien sa politique), je paye déjà $99 pour avoir le droit de passer par l'AppStore d'Apple sinon les utilisateurs sont moins chauds à installer (et bonus, ils payent), et sans signature les prochains Mac refuseront par défaut de faire tourner un binaire non signé. Ca ne fait que commencer…
Bref, propose mieux, mais pour le moment si on veut de la sécurité (car ça reste de la sécurité dans un monde qui s’intéresse de plus en plus à ta machine) du développeur jusqu'à l'utilisateur, ben c'est le moyen trouvé. la façon linuxienne n'est pas généralisable car ne répond pas du tout au besoin global (dépots officiels, très sélectifs d'une sur les licences, et ensuite faut trouver un "sponsor" sans aucune garantie d'en trouver un un jour même si on a la bonne licence, bref c'est gratuit mais le service est moins bien, quand on accepte de te livrer le service).
[^] # Re: Complément
Posté par claudex . Évalué à 4.
Uniquement sur PC.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.