Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
721 connectés 

  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Intel 100% UEFI 0% BIOS d'ici 2020

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[HFR] Actu : Intel 100% UEFI 0% BIOS d'ici 2020

n°10277552
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 20-11-2017 à 11:33:09  profilanswer
0Votes positifs
 

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 ...

mood
Publicité
Posté le 20-11-2017 à 11:33:09  profilanswer
 

n°10277556
Oxygen3
Tears from the moon
Posté le 20-11-2017 à 11:35:28  profilanswer
0Votes positifs
 

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

n°10277557
ockiller
Posté le 20-11-2017 à 11:38:34  profilanswer
8Votes positifs
 

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

n°10277558
Usernet
Since 2004
Posté le 20-11-2017 à 11:38:57  profilanswer
4Votes positifs
 

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)


Message édité par Usernet le 20-11-2017 à 11:41:40
n°10277560
JechtPurga​teur
Posté le 20-11-2017 à 11:39:30  profilanswer
2Votes positifs
 

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.

n°10277564
errorsyste​m29
Posté le 20-11-2017 à 11:46:46  profilanswer
0Votes positifs
 

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.

n°10277566
Mysterieus​eX
Chieuse
Posté le 20-11-2017 à 11:50:02  profilanswer
0Votes positifs
 

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)

n°10277604
src386
Posté le 20-11-2017 à 13:03:18  profilanswer
1Votes positifs
 

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

n°10277610
Vaestmanna​eyjar
Posté le 20-11-2017 à 13:22:20  profilanswer
14Votes positifs
 

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

n°10277611
guig2000
Posté le 20-11-2017 à 13:22:41  profilanswer
3Votes positifs
 

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

mood
Publicité
Posté le 20-11-2017 à 13:22:41  profilanswer
 

n°10277614
Antimasse
Posté le 20-11-2017 à 13:24:23  profilanswer
0Votes positifs
 

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.
 
 


Message édité par Antimasse le 20-11-2017 à 20:20:38
n°10277625
raptor68
Pouet !
Posté le 20-11-2017 à 13:55:33  profilanswer
0Votes positifs
 

Antimasse a écrit :


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 adapté au hardware. Il suffit de voir comment Android boot pour voir où on va.

 

Résultat, et vu les restrictions que quelques OEM font sur certains laptops (coucou Lenovo où tu ne nous autorise pas à installer Linux) ç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)


Message édité par raptor68 le 20-11-2017 à 13:58:55
n°10277635
valeoscoot
Posté le 20-11-2017 à 14:14:32  profilanswer
1Votes positifs
 

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.

n°10277636
Svenos
Posté le 20-11-2017 à 14:16:44  profilanswer
4Votes positifs
 

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...

n°10277637
valiran
Posté le 20-11-2017 à 14:20:56  profilanswer
0Votes positifs
 

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.

n°10277638
Antimasse
Posté le 20-11-2017 à 14:21:36  profilanswer
0Votes positifs
 

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é, .


Message édité par Antimasse le 20-11-2017 à 17:58:26
n°10277640
valeoscoot
Posté le 20-11-2017 à 14:25:13  profilanswer
2Votes positifs
 

valiran a écrit :

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.


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.

n°10277642
Antimasse
Posté le 20-11-2017 à 14:29:56  profilanswer
1Votes positifs
 

raptor68 a écrit :


 
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)


 
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.


Message édité par Antimasse le 20-11-2017 à 23:06:51
n°10277649
loustic
Posté le 20-11-2017 à 14:40:23  profilanswer
4Votes positifs
 

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

n°10277691
helionn
Posté le 20-11-2017 à 15:47:44  profilanswer
2Votes positifs
 

Vaestmannaeyjar a écrit :

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


 
"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 !"


Message édité par helionn le 20-11-2017 à 15:50:24
n°10277696
HashBoost
Posté le 20-11-2017 à 16:06:36  profilanswer
3Votes positifs
 

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 !

n°10277724
luxy
the future is ZEN
Posté le 20-11-2017 à 17:06:25  profilanswer
3Votes positifs
 

je suis chez AMD, vive le bios !

n°10277735
cbeny38
Posté le 20-11-2017 à 17:23:59  profilanswer
0Votes positifs
 

"... 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 ?

n°10277747
Antimasse
Posté le 20-11-2017 à 17:41:47  profilanswer
3Votes positifs
 

HashBoost a écrit :

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 !


 
Ç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)


Message édité par Antimasse le 21-11-2017 à 14:54:52
n°10277767
B00lay Ier
Posté le 20-11-2017 à 18:10:58  profilanswer
0Votes positifs
 

HashBoost a écrit :

Et pourtant, l'UEFI est un très gros progrès par rapport au BIOS : (...)
 
- Pour les programmeurs, un BIOS UEFI se code en C alors que l'ancien était en assembleur.
 
Et j'en oublie surement !


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 :o
 
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.

n°10277786
Mysterieus​eX
Chieuse
Posté le 20-11-2017 à 18:43:32  profilanswer
0Votes positifs
 

Antimasse a écrit :

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 adapté au hardware. Il suffit de voir comment Android boot pour voir où on va.
 
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.
 
 


 
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.

n°10277787
superradad​a
Posté le 20-11-2017 à 18:47:16  profilanswer
0Votes positifs
 

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

n°10277839
Antimasse
Posté le 20-11-2017 à 20:11:23  profilanswer
0Votes positifs
 

MysterieuseX a écrit :


 
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.


 
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.

Message cité 1 fois
Message édité par Antimasse le 21-11-2017 à 14:55:42
n°10277883
valeoscoot
Posté le 20-11-2017 à 21:40:32  profilanswer
1Votes positifs
 

Antimasse a écrit :


 
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, 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.

n°10277903
bluedragon​38
Posté le 20-11-2017 à 22:52:12  profilanswer
0Votes positifs
 

JechtPurgateur a écrit :

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.


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

n°10277988
src386
Posté le 21-11-2017 à 09:16:57  profilanswer
0Votes positifs
 

HashBoost a écrit :

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 !


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


---------------
MSI B350M MORTAR, R7-1700X, KFA2 HOF-3600 16GB (16-18-18-38), KFA2 GTX1070 EX
n°10278126
Antimasse
Posté le 21-11-2017 à 12:18:04  profilanswer
0Votes positifs
 

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.


Message édité par Antimasse le 21-11-2017 à 12:22:38
n°10278840
guig2000
Posté le 22-11-2017 à 13:30:31  profilanswer
1Votes positifs
 
mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Intel 100% UEFI 0% BIOS d'ici 2020

 

Sujets relatifs
PC sans bios: écran noirRésolution d'affichage dans le bios
bios puis écran noirmodification bios acer aspire 5733
[HFR] Actu : Qualcomm dit non à Broadcom[HFR] Actu : Bientôt (enfin !) des RX Vega 56 customs ?
[HFR] Actu : Intel met Broadwell-E à la retraite 
Plus de sujets relatifs à : [HFR] Actu : Intel 100% UEFI 0% BIOS d'ici 2020


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR