Malgré, le titre bien long, ce journal est essentiellement un marque page (lien). Apparemment une nouvelle faille ferait trembler l'industrie informatique. L'occasion pour d'aucuns (votre serviteur inclus) de découvrir un aspect rarement souligné de l'UEFI qui se trouverait également être un digne héritier des très honnis modules TPM de mirosoft (?) : de mini-ordinateurs contrôlant votre utilisation de nos leurs machines, une espèce de DRM incontournable. Comme d'habitude, la morale la plus élémentaire et les associations de protection des libertés comme l'EFF s'élevaient en vain contre l'inclusion de dispositifs de surveillance à distance des ordinateurs : outre le côté intrusif à la Big Brother, des failles allaient nécessairement s'y trouver et se voir exploitées. Bingo !
Tout cela et bien plus d'informations autrement plus précises se trouve très bien décrit dans (et à partir d') un excellent résumé sur pluralistic.
# du dur ou du cloud
Posté par orfenor . Évalué à 2.
Je n'ai pas lu de fond en comble la description de la faille. Cependant ça ne concerne que les ordis physiques n'est-ce pas ? Tout est tellement virtualisé dans les cloud, que l'impact ne me parait pas si grand.
[^] # Re: du dur ou du cloud
Posté par ted (site web personnel) . Évalué à 5.
Je ne sais pas si ça concerne que les ordinateurs physiques, une VM peut bien booter en PXE aussi. Les ordinateurs virtuels peuvent être patchés plus facilement.
Dans tous les cas il faut bien un ordinateur physique pour faite tourner des VM, si l'hôte est compromis je ne vois pas comment l'invité peut être mieux protégé.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: du dur ou du cloud
Posté par orfenor . Évalué à 3.
Encore faut-il avoir accès à l'hôte, non ?
[^] # Re: du dur ou du cloud
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Bah s'il y a une faille sur l'hôte, on y a accès. Enfin évidemment ça ne veut pas dire que demain tous les PC, tous les serveurs et tout vont être infectés par un vers par cette faille. Mais il est aussi évident que c'est possible au moins si l'on est sur le même réseau. Et les majors du hacking n'ont elles pas déjà des virus installés un peu partout?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: du dur ou du cloud
Posté par Astaoth . Évalué à 6.
Ca concerne toutes les implémentation d'UEFI ayant ces vulnérabilités.
"The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft.".
J'imagine qu'on peut supposer qu'un UEFI open source peut largement être utilisé dans le monde de l'hypervision, et notamment des hyperviseurs open-sources.
Emacs le fait depuis 30 ans.
# Un journal très orienté
Posté par Astaoth . Évalué à 10. Dernière modification le 19 janvier 2024 à 03:08.
Je ne suis pas sûr de comprendre le rapport entre l'attaque découverte et le contenu du journal.
L'attaque exploite une chaine de vulnérabilité sur les boots PXE et l'IPv6 de l'UEFI. Je ne suis pas sûr de comprendre le rapport avec les TPM du coup.
D'après Wikipedia, "Trusted Platform Module (TPM) was conceived by a computer industry consortium called Trusted Computing Group (TCG)." et "Members include Intel, AMD, IBM, Microsoft, and Cisco.". Du coup les TPM n'ont pas été créées juste par Microsoft.
Les TPM en tant que telles ne servent qu'à stocker des clefs et signatures cryptographiques, et il est totalement possible de les effacer et d'y mettre les siennes. C'est long et pénible, mais faisable sous le contrôle de l'utilisateur qui souhaite avoir son propre set de clefs et signatures. Si l'utilisateur ne veut pas s'embêter avec ca, il peut aussi juste désactiver le Secure Boot, comme à l'époque des BIOS. Du coup je ne vois pas trop le rapport avec les DRM.
Le journal fait mention de dispositifs de surveillance dans les ordis modernes après avoir parlé d'UEFI, de TPM et de cette nouvelle attaque.
Pour rappel, les TPM et UEFI n'ont rien à voir avec des dispositifs de surveillance. La fonction d'une TPM est de répondre à ce problème très bête et très dur à résoudre de "l'evil maid attack".
L'UEFI a été créé pour remplacer un BIOS vieillissant (il me semble que, un compatible-PC, à l'étape du BIOS, émule littéralement un IBM PC d'il y a 40 ans ; ca devient un peu long de compter quelques dizaines de Go de RAM pendant un POST), dont les mises à jours sont plus que scabreuses (en cas de plantage d'une maj, il faut remplacer la puce du BIOS par une nouvelle, flashée avec le firmware), et créé à une époque où les besoins en sécurités étaient différents.
Les buts et fonctionnalités initiales de l'UEFI sont plus ou moins les mêmes que celui des BIOS : être une interface basique d'exploitation du matériel et lancer le bootloader. Bien évidement qu'un UEFI peut exploiter le matériel, exactement de la même facon q'un BIOS peut le faire. D'ailleurs les boots PXE ne sont pas apparu avec les UEFI, donc rien ne dit que cette attaque n'existait pas avec les BIOS, mais n'a pas été découverte officiellement. On a d'ailleurs pas attendu les UEFI pour trouver des attaques sur les firmwares, je me souviens d'une histoire de disques durs d'il y a quelques années à ce sujet.
Ce journal parle enfin d'éthique sur les firmwares, et semble sous-entendre que les UEFI ne sont pas éthiques. Au vu de l'évolution de la recherche en sécurité durant la dernière décade, et des fonctions très similaires entre les BIOS et UEFI, est-ce que l'absence d'attaque connue de ce type sur les BIOS implique nécessairement leur impossibilité ? Et quel rapport avec l'éthique en fait ?
Pour rappel, la chaine de vulnérabilité nécessaire à cette attaque est disponible sur au moins un UEFI open-source, l'implémentation de référence d'Intel (sous licence BSD). Si j'ai bien compris la page wikipedia de EDK II (l'UEFI de Intel), il fait maintenant parti de Coreboot, la stack libre visant à remplacer les BIOS et UEFI. Mais peut-être que Coreboot n'est pas un projet éthique dans son principe ? D'ailleurs, serait-il plus éthique de ne pas avoir un firmware s'occupant de l'initialisation du matériel, du lancement du bootloader et présentant une interface standardisé du matériel à l'OS, et donc de devoir dépendre du bon vouloir des fabriquant de cartes mères ?
Et enfin, cette attaque nécessite une chaine de vulnérabilité assez importante (9 vulnérabilités du coup), et a comme pré-requis d'avoir le PXE actif, et peut-être aussi de l'IPv6 (sur certains UEFI, on peut choisir d'avoir du PXE uniquement en v4 ou v6). Cette vulnérabilité semble donc assez simple à mitiguer pour un particulier. Pour les UEFI virtuels, une mise à jour de l'hyperviseur corrigera les vulnérabilités ; pour les UEFI matériels, une mise à jour, faisable depuis l'OS pourra également bloquer l'attaque. Avec un BIOS, ce genre de patch serait beaucoup plus pénible à appliquer sur les environnements physiques, car il ne pourrait se faire que manuellement, en démarrant non pas l'OS mais directement le firmware de màj du BIOS, avec toujours le risque que si la màj se vautre, il faut remplacer la carte mère.
En conclusion, je trouve qu'utiliser un article sur une attaque d'un composant matériel pour dire que celui-ci ainsi qu'un autre composant matériel (pas impacté par l'attaque) sont des techno de surveillance, voir des backdoors, c'est assez peu éthique je trouve.
Emacs le fait depuis 30 ans.
[^] # Re: Un journal très orienté
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Voilà qui ne surprendra guère l’ancien dernier de classe en expression écrite que je suis. J’ai tenté de mettre en avant quelques éléments fort de l’article de C. Doctorow lié en introduction et conclusion. Sans le lire, il paraît délicat de comprendre ce journal marque-page.
Par ailleurs vous avez parfaitement raison de qualifier mes propos de très orientés. À l’exception des plaisanteries qui sont animés d’une espèce de mouvement brownien, mes propos le sont assez systématiquement. Mon journal ne se veut pas qu’informatif. Je n’aurai renvoyé que le lien sur arstechnica sinon.
Là n’est pas mon propos. Monsieur Doctorow l’écrit assurément mieux que moi : l’implémentation matériel d’un logiciel tournant hors de portée des utilisateurs — initialement destinée à des technologies de surveillance — et accessoirement employée dans l’UEFI, voici ce qui me semble devoir être dénoncé comme transgression morale, en profitant de l’occasion donnée par la découverte de cette faille. Nul besoin d’être grand clerc pour deviner que pour une faille exposée, il doit s’en trouver bien d’autres exploitables, bien difficiles à corriger et surveiller de part le choix initial du design basé sur une technologie de surveillance.
Mon expression reste toujours aussi médiocre. Pour comprendre il vaudra mieux lire l’article. Permettez-moi d’ajouter que, par ailleurs, je n’ai pas de connaissances importantes en matière de firmware, et que donc mon propos ne fait que rapporter celui d’autrui. Mon jugement technique n’a que peu de valeur dans le domaine que nous discutons.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un journal très orienté
Posté par Astaoth . Évalué à 3.
"Cory Doctorow, né le 17 juillet 1971 à Toronto en Ontario, est un blogueur, journaliste et auteur de science-fiction canado-britannique."
Je ne vois pas de bagage technique dans son CV, du coup je doute de la pertinence d'utiliser ses propos comme référence sur un sujet assez technique et méconnu. En particulier quand il compare la TPM à un composant de vaisseau interstellaire qui mène à l'explosion de celui-ci, dans un film de science-fiction.
La TPM n'est toujours pas une techno de surveillance comme tu le sous-entends. C'est une réponse à "l'evil maid attack", la seule possible à l'heure actuelle. Je t'encourage très fortement à lire la page wikipedia à son sujet.
En dehors d'une surveillance permanente de l'équipement, les seules facons de contrecarrer cette attaque, et donc toute modification de la chaine de boot qui ne peut pas être chiffré sur un volume LUKS c'est de signer les composants logiciels, et de mesurer leurs temps d'exécutions. Un PC et un programme étant déterministes, tant que le bootloader n'est pas modifié, la durée d'exécution de chacune de ses étapes doivent être strictement identique d'un boot à l'autre. Un changement de durée d'exécution indique une modification du bootloader. Contrairement à ce qu'a écrit ton auteur de SF préférée, la TPM ne surveille pas l'ensemble des logiciels qui tournent sur le PC, mais uniquement ceux de la phase de boot, quand le SecureBoot est actif.
La TPM ne serait une technologie de surveillance de l'utilisateur que si ses fonctionnalités ne pouvaient pas être désactivées (et on peut allègrement passer outre la TPM en désactivant le secure boot, encore une fois), si elle stockait les infos de chaque boot (c'est pas le cas, elle compare les durées d'exécutions et des signatures seulement, sans plus, et je doute un peu qu'elle ait les capacités de stockage pour stocker les données de tout les boots d'un PC), et si elle transmettait ces informations à des acteurs extérieurs (c'est toujours pas le cas, la TPM n'a pas de stack réseau). Et avant de faire un lien bancale entre la TPM et l'UEFI, il est totalement possible de trouver des TPM externe, qu'on utiliserait sur un raspi qui n'a pas d'UEFI. L'hypothèse que la TPM a été créé comme un dispositif de surveillance de l'utilisateur est donc erronée. Mais tout ceci n'a toujours aucun rapport avec l'attaque de l'article de Ars Technicas.
Même un firmware de hardware libre reste hors de porté de l'utilisateur, en particulier de ceux n'ayant aucun bagage technique. Mais si les firmwares qui proposent des interfaces standardisés par des normes ISO pour les OS et drivers n'existaient pas, l'utopie d'avoir des OS indépendants de grosses sociétées resterait une fiction. Pour en avoir une vague idée, souvenons-nous de la sombre époque de ndiswrapper pour le wifi, et imaginons un seul instant être dans la même situation pour l'accès aux volumes de stockages par exemple.
Au vu du contenu de son article, c'est également le cas de Cory Doctorow. Le problème est qu'il a pris des morceaux d'info ici et là, sans vraiment les comprendre, et au lieu de creuser le sujet, il les a assemblé à la facon d'un blogueur, journaliste et auteur de science-fiction. Malheureusement pour lui, nous ne sommes pas dans un roman de science-fiction, la TPM n'a pas les buts et fonctionnalités qu'il décrit, et les scénarios catastrophes qu'il mentionne restent … de la fiction.
Renseigne-toi vraiment sur ce qu'est une TPM, mets en place un secure boot, et testes les scénarios catastrophe de ton auteur préféré (lorsque possible) pour voir si ils sont réalistes ou non (par exemple, essaye d'avoir un ad-blocker dans ton navigateur web et vois si la TPM t'en empêche avec un secure boot actif).
Emacs le fait depuis 30 ans.
[^] # Re: Un journal très orienté
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Cory Doctorow, est extrêmement connu pour avoir fait parti de l'EFF et pour avoir lutter contre les DRM depuis 2005.
La spécification TPM proposait de vérifier toutes la chaines d’exécution et pas seulement le boot.
A l'origine, la root key du TPM ne devait pas être sous le contrôle de l'utilisateur.
Un PC et un programme ne sont pas du tout déterministes. La vitesse d’exécution s'ajuste selon la température et la charge, ces petits changements entrainent aussi des modifications d'utilisation des caches ce qui augmentent encore les différences. A voir si ces métriques sont encore utilisés, mais il était surtout question de hash et de signature.
Le TPM gére le démarrage d'un PC, utiliser une carte à puce sur un raspberry pi n'en fait pas un TPM.
"La première sécurité est la liberté"
[^] # Re: Un journal très orienté
Posté par Astaoth . Évalué à 5. Dernière modification le 19 janvier 2024 à 18:31.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans.
[^] # Re: Un journal très orienté
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 19 janvier 2024 à 15:46.
Serait-il possible de faire des micro-ordinateurs moderne sans BIOS/UEFI ? (Ça existe pour les vieilles consoles).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un journal très orienté
Posté par flavien75 . Évalué à 4.
Je ne vais malheureusement pas avoir le temps de te faire une réponse complète, mais c'est un sujet dont on avait parlé dans les commentaires du journal sur Petitboot.
TLDR: Il faut que lors du reset, le CPU ait une procédure de démarrage simple. Dans le cas des vieilles consoles, l'adresse 0 de l'espace mémoire pointait sur le début de la ROM (intégré ou pas dans les cartouches), donc il suffisait juste au CPU d’exécuter les instructions situées au début de la ROM.
Depuis, les périphériques et leurs techniques d'accès se sont complexifiés, donc c'est devenu impossible sans avoir au minimum un bootloader.
Les vrais naviguent en -42
[^] # Re: Un journal très orienté
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Le principe d'un boot est de récupérer un blob mémoire quelque part puis de le copier en RAM et de l'executer. Le BIOS faisait ça avec le secteur de boot de mémoire.
N'importe quel cpu pourrait faire cela depuis une simple mémoire flash.
L'UEFI est infiniment plus complexe.
"La première sécurité est la liberté"
[^] # Re: Un journal très orienté
Posté par Renault (site web personnel) . Évalué à 3.
Oui enfin c'est une vision naïve du boot ça.
Le but est aussi d'initialiser le matériel et de gérer certains cas courants type démarrage par le réseau, affichage à l'écran, possibilité de configurer certaines choses liées au matériel, etc.
Le but de l'UEFI et du BIOS à cet égard est de fournir une abstraction commune, cela permet d'avoir des OS assez génériques compatibles avec toutes les machines tout en ayant une expérience utilisateur acceptable et des fonctionnalités avancées.
On le voit qu'on peut faire sans, l'ARM sans UEFI en est un cas facile à observer. Et faire un OS générique qui tourne dessus n'est pas trivial.
[^] # Re: Un journal très orienté
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
C'est pas naïf, c'est comme cela que cela marche. Ensuite, tu peux avoir des couches plus ou moins complexe.
Le BIOS à l'origine ne copiait que les 512 octets du boot sector du disque de boot. Ensuite, ce code prenait la main.
Tu peux imaginer un petit linux qui provoque un boot PXE pour booter depuis le réseau, sans avoir besoin de driver réseau au niveau du firmware.
Tu peux imaginer aussi un romcode qui contient des boot USB/SD/etc… comme sur OMAP. Le problème déjà cité par Linus Torvalds concerne la mise à jour impossible de ce genre de code. Cela veut dire qu'il faudrait plutôt le minimiser.
La seul initialisation un peu sensible que j'ai vu, c'était des timing de DRAM pour un boot sur OMAP.
"La première sécurité est la liberté"
[^] # Re: Un journal très orienté
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Peut être qu'on pourrait concevoir des PC plus simples ?
Pour faire un café, on a bien le choix entre le low tech (cafetière italienne) et le high tech (machine à expresso/mocha/capucho/… avec broyeur, écran et réveil) :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un journal très orienté
Posté par Toufou (site web personnel) . Évalué à 0.
Tutututu tout ça c'est bien relatif : la cafetière à piston est encore plus moins technique, monsieur !
Ou encore plus plus low tech : la chaussette ou le bon vieux filtre !
[^] # Re: Un journal très orienté
Posté par cg . Évalué à 4.
Pour compléter ce qu'a dit flavien75, oui c'est possible. Tu pourrais même avoir un jeu vidéo sans OS du tout, système mono-tâche qui n'a qu'un navigateur, démarré sans OS et sans tout le tralala, mais qui implémente tout le code nécessaire pour accéder au matériel1.
Il faudrait donc se débarrasser d'un bon paquet d'abstractions, de la modularité, et d'une certaine manière du standard d'accès qui sont offerts par le BIOS/l'UEFI et les systèmes d'exploitations, pour tout avoir exactement adapté à la machine. Je crois que les Unikernels sont proches de ça.
Si tu n'as jamais essayé, tu peux essayer de programmer en C ou assembleur pour la plateforme Arduino (25€), tu gères directement la flash et les accès mémoire en flash ou RAM, mais sans la galère d'un CPU complexe, juste un MCU. Dans le même esprit que VanillaJS ;). ↩
[^] # Re: Un journal très orienté
Posté par Renault (site web personnel) . Évalué à 5.
Les unikernels sont plus des sortes de bibliothèques pour que ton application fusionne avec le noyau pour former un binaire unique (enfin, sans doute qu'il y a des implémentations avec plusieurs binaires). Du coup au lieu d'appeler des appels systèmes tu y accèdes comme une fonction normale. Et avec une configuration adaptée, tu supprimes tout le code inutile comme quand tu supprimes les modules inutiles du noyau Linux pour tourner sur ta machine.
Cela n'empêche pas malgré tout de l'abstraction qui permet notamment de facilement partir d'une configuration pour créer les liens dans le code qui vont bien sans que l'application ait besoin d'être réécrite pour chaque plateforme.
[^] # Re: Un journal très orienté
Posté par barmic 🦦 . Évalué à 3.
Les unikernels sont un sujet orthogonal, il me semble. Le fait de démarrer un OS (que ce soit une application avec un unikernels, linux ou autre) sans code d'initialisation type bios/uefi demande à ce que tu ai une compilation pour chaque machines différentes sur le quel on veut qu'il démarre. Comme il ne peut pas découvrir le matériel, il faut le connaître à la compilation.
C'est la différence entre les ordinateurs compatibles (dans le quel on a pleins d'acteurs qui créent du matériel qu'on peut assembler comme on le souhaite) et les microordonateurs dont le nombre de machines différentes est dénombrable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un journal très orienté
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu sous-entends que la découverte de matériel ou le scan du PCI express nécessite le Bios/UEFI ?
"La première sécurité est la liberté"
[^] # Re: Un journal très orienté
Posté par barmic 🦦 . Évalué à 2.
Je ne le sous-entends pas, je l'affirme en expliquant que c'est de ce que j'en sais. Je dis que de ma compréhension, les différents protocoles d'auto découverte sont gérés par les bios et uefi. Je ne connais pas de boot genre lilo ou grub qui se substituerais au bios et uefi.
Mais n'hésite pas à m'expliquer où je me plante.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un journal très orienté
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'était une vrai question. Je sais qu'il existe des tables PCI pour la découverte de ce qui est branché dessus (des ID de périphérique + des adresses de mémoires). Mais il me semble que Linux utilise des appels UEFI ou Bios pour les lire, mais je ne sais pas pourquoi il ne le fait pas directement.
"La première sécurité est la liberté"
[^] # Re: Un journal très orienté
Posté par gUI (Mastodon) . Évalué à 5.
Oui, c'est d'ailleurs le cas de ton smartphone ou d'un RPi. Dans le monde embarqué (et ARM) c'est toujours le cas en fait.
Mais l'inconvénient est que tu dois alors décrire toi-même le matériel (Device Tree par exemple), et on perd le concept de PC "plug&play". C'est entre autre (il y en a d'autres) la raison pour laquelle il n'y a pas d'OS "universel" de smartphone.
Mais dans l'absolu techniquement oui, monter un PC "moderne" sans BIOS/UEFI avec du matos dernier cri ce serait tout à fait possible.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.