UEFI en question

Posté par . Édité par Benoît, Nÿco, patrick_g, Florent Zara, baud123, NeoX et tuiu pol. Modéré par Florent Zara. Licence CC by-sa
Tags :
26
5
juin
2012
Matériel

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

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.

  • # Pas intéressant ?

    Posté par . Évalué à 10.

    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.

    Et pourquoi pas ?

    • [^] # Re: Pas intéressant ?

      Posté par (page perso) . É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 :

      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.

      On se demande à quoi ça sert !

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Pas intéressant ?

        Posté par . É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 (page perso) . É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 . É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 . É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 . Évalué à -9.

        Encore une connerie.

        Prouve moi que Windows ne respecte pas ACPI.

        • [^] # Re: Pas intéressant ?

          Posté par . É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 . É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 . Évalué à 3.

          • [^] # Re: Pas intéressant ?

            Posté par . É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 . É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 . É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 . É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 . É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 . Évalué à 10.

                      Pourquoi donc est-ce que notre compilo devrait etre prevu pour d'autres OS ?

                      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 . É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 (page perso) . É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 . É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 . É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 . É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 . É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 . É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 . É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 (page perso) . É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 . Évalué à 5. Dernière modification le 06/06/12 à 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 . É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 . Évalué à 5.

                    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.

                    '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 . Évalué à -8.

                Moi je ne lance pas d'accusations, je n'ai rien a prouver.

  • # ARM != mobile

    Posté par (page perso) . Évalué à 7.

    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.

    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 (page perso) . É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…

  • # Custom mode ?

    Posté par (page perso) . É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 . É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 (page perso) . Évalué à 2.

      Pas de Custom Mode sur les uefi ARM compatibles Windows 8.
      Le Custom Mode est uniquement disponible pour les uefi x86(-64).

  • # plate-forme Intel ... et AMD ?

    Posté par . É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 (page perso) . Évalué à 6.

      vraiment limité au matos Intel ?

      Un itanium dans un smartphone, ça réchauffe bien les oreilles.

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: plate-forme Intel ... et AMD ?

        Posté par . É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 . É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 (page perso) . Évalué à 5. Dernière modification le 06/06/12 à 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 (page perso) . Évalué à 6. Dernière modification le 06/06/12 à 08:18.

    cela ne concerne que les smartphones et tablettes Windows : soit une part de marché faible

    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 . Évalué à 3.

      si Nokia arrive à se remettre dans la course

      avec des si…

      • [^] # Re: Anecdotique ?

        Posté par . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 4.

          et tu récupères un binaire signé avec la clé Microsoft quelque temps plus tard.

          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 . É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 . Évalué à 1. Dernière modification le 06/06/12 à 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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . Évalué à 4.

              (les geeks pouvant décocher la case dans UEFI)

              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 à ceux qui les ont postés. Nous n'en sommes pas responsables.