Au cours d'une présentation donnée lors de l'UEFI Plugfest d'Octobre, Brian Richardson d'Intel a indiqué que les plates-formes et client et serveur d'Intel ne ...
Lire la suite ...

Les vieux OS pourraient toujours fonctionner avec un bidouille basée sur un hyperviseur léger enchainant un boot automatique d'une VM "legacy".

Nos PC ne seront donc plus 100% compatibles IBM-PC ?

Mdr j'y pensais tout le weekend ^^
 
http://forum.hardware.fr/hfr/Hardw [...] 5297_1.htm
 
C'est devenu un beau bordel d'installer MS-Windows dessus..
Attention que le secureboot ne devienne pas trop sectaire au point de ne plus pouvoir installer autre chose que du MS (ex : un linux)

Arium10 par exemple n'est pas encore en legacy ?
J'ai un pc sans CSM qui ne peut pas boot sur Arium10 et c'est la seule explication que je vois.
C'est dommage d'abandonner ça, je comprends pas ce que ça apporte.

Si on peut toujours overclocker, booter sur ce que l'on veut et mettre à jour tout ça sans problème de démarrage et sans OS(pour un PC neuf), alors c'est un grand oui.
Si AMD fait pareil ça sera parfait.

Autant on peut faire tourner UEFI sur BIOS (bootloader type clover Marc ?) Autant l'inverse est également vrai, ou chainloader.
 
PS : TOUT les os supportent le chainloading et le bootstrapping (= passage de physique à soft et vise et versa)

Ah oui c'est comme le VGA.
Oh wait...

"Ah, et pour que tout soit compatible, on va changer de socket".

Comment je fait pour booter sur ma carte raid matérielle ou mes vieux CD ide sans bios?

Faut juste espérer qu'Intel ne force pas la classe 3+ ("Secure Boot" requis), car ça va inciter les autres à la faire.
Mais je trouve ça naïf d'y croire, vu le slide de Brian Richardson, avec son ton qui montre qu'il veut clairement imposer quoi qu'il arrive ses "visions".
 
Vu que ça parle de chainload, on peut chainload quasi aussi facilement sur UEFI (avec et sans "Secure Boot'" ) que sur BIOS avec Linux ou Windows ?
 
 
Sinon, cette news tombe à pic, je voulais aborder ce sujet quasi relatif:
 
L'arrivée d'ARM sur le monde PC est pas une bonne chose, parce que pour booter, il n'y a pas de BIOS ou d'UEFI.
Pour ce faire, faut avoir un kernel/drivers/blob adapté au hardware. Il suffit de voir comment Android boot pour voir où on va ou encore ici: https://community.arm.com/processor [...] 53792398=1
 
Résultat, et vu les restrictions que quelques OEM font sur certains laptops (https://www.reddit.com/r/linux/comments/53ri0m/warning_microsoft_signature_pc_program_now/) ça va nous empêcher d'installer l'OS qu'on veut et même apporter de la fragmentation d'OS comme sur Android.
 
Bref, n'achetez pas du ARM pour PC tant qu'il n'y aura pas d'UEFI, avec "Secure Boot" desactivable.
 
 

La plupart du temps android démarre via uBoot, secteur de démarrage bien connu du monde de l'embarqué. mais si tu prends l'exemple du raspberry, le firmware est sur une partition FAT32, et sur windows IOT pour raspberry, tu verra qu'ils ont un bootloader ... EFI tout comme windows RT. En tout cas, sur la première version que j'ai testé

Pour lenovo, j'ai eu une Yoga Tab 2. Bien que le produit ne soit pas bien fini et que le port USB n'ai aucune protection surtension, le problème de linux viens du couple intel/microsoft (windows 8 avait un bug en 64 bit empèchant la veille prolongée de fonctionner correctement et l'EFI étant compilé pour une archi, ils ont privilégié le 32 bits) et tu verra que le problème est commun à toutes les tablettes et petits portables sous Z3575 et consorts (même si aujourd'hui, de plus en plus de linux ont des bootloader ia32, mais il aura fallu plusieurs années)

Un système de boot sécurisé sur un ordinateur domestique est sécurisé contre son propriétaire, c'est à dire contre nous.
Y'a pas matière de se réjouir.

En tout cas l'UEFI dernièrement a permis à un partnership bien salace entre microsoft et intel avec la soi disant incompatibilité de windows 7 avec les dernières plateformes intel.  
Ca ressemble quand même pas mal à une contre-mesure technique coordonnée pour rendre fastidieuse l'installation de windows 7 et faire abdiquer l'utilisateur lambda et le forcer à passer au 10.  
Sur la quasi totalité des forums ou des gens avaient des soucis d'instal win 7 se voyait proposer passer au 10 sans proposer de solution ou alors des options contraignantes alors qu'un simple lecteur cd ou une iso modifiée avec NTlite suffit à résoudre la plupart des soucis d'instal.
 
D'un côté Intel prétend que sa plateforme est incompatible et de l'autre Microsoft bloque les mises à jours. Qui voudrait sur windows 7 des mises à jours récentes, la plupart des dernières qui sont sortie implantent toute la partie malveillante dite "anti malveillant" des composants windows 10...  
 
Quant aux secure boot a t'il réellement protégé des postes informatique ou au contraire causer plus de contraintes aux utilisateurs finals? Avec mon experience, certes modeste je n'ai jamais rencontré de différence entre une legacy et une secureboot lors des scan malware, pup, rogue, rootkit, junkware etc... En revanche pour installer un autre OS ou récupérer des données, c'est souvent un beau bordel avec les bios des pc portable ACER, HP, Toshiba, Lenovo...

Vous vous posez des questions là où il n'y en a pas.
La grosse majorité des possesseurs d'ordinateurs n'y verront que du feu.
Ils pourront toujours aller sur Facebook et lire leurs mails.
Nous ne sommes qu'une petite poignée à être vraiment impactés.

Pas vraiment qu'une poignée à être impactés.
Dans un autre monde, ils le sont tous mais ils ne le savent pas: La fragmentation d'Android et l'API (version d'Android) requis pour que certaines apps puissent s'installer en est la preuve. Quand bien même l'hardware suit très bien.
 
Ça peut donc tout aussi bien s'appliquer au monde PC.
 
 
Le problème c'est les implementations modernes de ces sécurités.
Ils sont sur-complexifies, donc ça rajouté des points d'attaque comme la partition ESP par exemple (fragile en plus, car Fat32 !)
 
L'autre problème, c'est qu'ils rajoutent des verrous numériques ou du bloatware (coucou les répertoires /EFI/ASUS, /EFI/LENOVO, /EFI/MSI, etc dans l'ESP) en prétextant la sécurité, .

C'est le problème. Et les décisions de justice se font de la même manière, avec des juges et magistrats aveugles technologiquement aux privations de libertés.

 
C'etait vrai pour les Atoms (Debian et autres gerent ca maintenant), mais je parlais malheureusement pas de ces Lenovos: https://www.reddit.com/r/linux/comm [...] ogram_now/
 
Pour l'UEFI sous Windows RT, je me rappelle pas qu'on ait réussi à correctement porter Linux sur une Surface 2, sauf si t'as une source bien entendu.
 
 
En gros:
 
Tu peux pas utiliser une iso ARM standard comme sur x64 via CD/DVD/USB pour l'installation, mais tu dois appliquer une image "pré-installée" limitée sur le stockage target pour que ça boot.
Même si Windows utilise l'EFI pour IoT core, ça reste le même principe sur-compliqué et dépendant du Kernel/Driver/Blobs.
 
En détail:
 
Pour les SoC en général, le gros problème vient des drivers.
Certains hardawre sont initialisés avant (pas que sur Raspberry Pi) le bootloader tel qu'on le connaît (u-boot, UEFI, BIOS, etc), si les drivers sont en general des blobs (proprietaires), ca devient ultra dur de boot.
 
En fait, c'est pour ça que créer des ROMs custom sous Android prends masse de temps, ou que certains devices sont abandonnés "sans raisons"
Soit ils reutilisent les blobs, et ça te bloque à une seule version de kernel (et donc à quelques versions d'Android max), soit ils reverse-engineer le truc mais c'est même pas à 90% stable la plupart du temps voire même impossible.

UEFI+W10+Cloud+Location au lieu d'achat=1984 et les veaux sont content.

 
"Non les gars !  
Selon les retours, les gens n'aiment pas les changements de socket...  
Donc on garde le socket mais ça ne sera pas retro-compatible"  
 
"C'est une révolution ! Il faut tout changer !"

Et pourtant, l'UEFI est un très gros progrès par rapport au BIOS :
- possibilité d'un nombre illimité de partitions reconnues au boot et non plus 4
- support des partitions supérieures à 2 To pour booter
- checksum en CRC32 pour l'intégrité des données
- plus de limite pour les ROM optionnelles dans la zone des 1 Mo, toute la mémoire est accessible
- Standardisation des protocoles pour accéder aux devices classiques (VGA, son, ethernet, etc..) ce qui permet de proposer des BIOS avec une belle interface, capable d'aller sur le réseau chercher ses mises à jour.
- Pour les programmeurs, un BIOS UEFI se code en C alors que l'ancien était en assembleur.
 
Et j'en oublie surement !

je suis chez AMD, vive le bios !

"... ce qui aura notamment pour impact de plus permettre l'installation et le démarrage de certains vieux OS (ancienne distribution GNU/Linux, DOS, Windows XP, Windows 32 bits…)"
 
ce qui aura notamment pour impact de "ne" plus permettre ?

 
Ça permet de belles choses et c'est indéniable.
 
Mais d'un autre côté l'update via réseau est une connerie sans nom pour la sécurité.
Sans parler de l'esthetisme qui n'a rien à faire avec un firmware qui se doit d'être aussi fiable que possible et donc sans bloat. D'ailleurs ils ne resemblent plus à rien (coucou Bling Bling génération Z) alors que pour naviguer rapidement, rien ne vaut des interfaces un minimum unifiées (BIOS).
 
Après, n'oublies pas qu'en apports négatifs, on a: Un vecteur d'attaque qu'est l'ESP (en plus d'être fragile, Fat32) et des sécurités à fins de verrous ("Secure Boot", "Boot Guard" et autres).
 
Utiliser le C est un point discutable, ça autorise plus de personnes à pouvoir le modifier (et à attaquer) comparé à l'ASM. Après, si ça nous permet de le reprogrammer nous-même hors-ligne et de manière accessible (ex: refaire les tables ACPI, etc) c'est ok.
 
 
Le progrès c'est bien seulement si ça apporte pas de gros inconvénients après.
 
Parce qu'à quoi ça sert d'avoir un PC si à cause d'un verrou dans l'UEFI on ne pourrait plus update l'OS dans le futur ? (Cf les SoC ARM + Android)

L'histoire du C c'est juste une contrainte d'ordre "matérielle" (obligation de répondre à un niveau minimum de fonctionnalité), en aucun cas une avancée en terme de facilité de développement
 
Je ne serais même pas étonné que ça ne soit en réalité qu'une conséquence de la nécessité de ce support pour une des évolutions par rapport au BIOS.

 
Secure Boot est un faux problème (déjà largement démontré) : tu peux installer tes propres platform key, avoir un secure boot fonctionnel et pas du tout passer par microsoft.
Pour le chainload, c'est plus simple sous UEFI que sous BIOS (pas de repassage en mode réel, pas de zerg des tables mémoires @640k), t'as de très bon bootloader qui gère le chainload (chameleon, clover, rEFInd)
 
Pour désactiver le secure boot sur arm "PC" c'est passage du device en dev mode.
 
De fait pour chainloader un bios derrière un UEFI : busybox qui passe en mode réel (hop). Pour chainloader un UEFI derrière un BIOS.
 
Et pour uniformiser le tout : coreboot.

En meme temps quand quelque chose a fait son temps il faut aller de l'avant .Je trouve normal de passer a autre chose pourvu seulement que ce soit mieux

 
Pour ceux qui veulent suivre et comprendre comment marche tout le bordel, lire surtout la 1ere page: http://www.linuxjournal.com/conten [...] ecure-boot
 
Secure Boot n'est pas un faux problème, car seul l'OEM peut décider si tu accèdes au custom mode (il n'est pas dispo sur les Asus Transformer sous Atom: https://www.youtube.com/watch?v=eDoP6h8TQw8) pour mettre tes pk. Et ça se confirme sur ARM, car dans certains matos tu n'y a pas accès. Ça peut donc très bien venir sur le monde PC x64 ou ARM.
 
Pour le chainload et la facilité, je parle pour l'end-user et l'OS en fait. Peut-il faire un chainload de manière simple comme ça a toujours été le cas sur Linux où via bcdedit (Windows) ? Ou il y a des étapes en plus à faire ?
 
Les bootloaders alternatifs que tu cités passent après le BIOS et l'UEFI, pour ce dernier tu dépends toujours du bon vouloir des OEM pour le custom mode.
 
Pour ce qui est du dev-mode: https://community.arm.com/processor [...] 53792398=1
 
Tu es dépendant du kernel/drivers/blobs, comme c'est généralement le cas sur ARM. Car dans le tutoriel, il te dit explicitement de récupérer les drivers Chrome OS pour les rapatrier sur ton Linux. Si il n'avait pas utilisé le même Kernel que ChromeOS, le rapatriement n'aurait peut-être pas marché.
 
Pour Busybox, ça reste toujours après UEFI, donc toujours la même histoire du bon vouloir des OEM pour le custom mode.
 
Et enfin Coreboot: C'est un projet que j'aimerais voir fleurir partout (surtout LibreBoot en fait), mais vu le peu d'implementation ça montre qu'on sera sévèrement limités dans nos choix hardware. Et ça signifie aussi écraser l'UEFI/BIOS, chose qui nécessite du matos assez spécial pour avoir vu ça à l'oeuvre et c'est encore plus risque qu'un simple flash BIOS.
 
 
Tu sembles bien informé du bordel, si tu as un moyen d'outrepasser les OEM sans avoir à dépendre de CoreBoot ou des remarques sur ce que j'ai dit, je suis volontiers preneur.

D'après ce que j'ai compris un OS peut même vérifier que le mode UEFI est secure et lui est dédié. En gros un OS peut exiger qu'une carte mère ne marche qu'avec lui. la définition même de la vente liée.

 
J'ai été voir .. version 1609.. LAUL !

Par contre tu ne peux plus prendre ton disque et le mettre dans une autre machine, ça ne boote pas.

Ah, tu m'intéresses.
 
Tu sais le pourquoi du comment ?
 
Normalement si le whitelist a le PreLoader ou le Shim ça devrait passer niquel partout non ?
Après j'exclus les entrées OEM de l'ESP, il faudra de toute façon les virer.

Ben non, si t'es méchante!