Discussion :

[codec_abc]

Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit
Par contre pour ceux qui se pencheront dessus, l'avantage que cela procure au programme c'est de pouvoir alors avoir un accès root mais plus que ça, pouvoir s'installer dans le système d'amorçage de l'ordinateur ou en mémoire noyau à un endroit ou il ne pourra pas être détecter par un anti-virus qui lui tourne en espace utilisateur (en root).
Alors il est vrai que ce n'est pas la peine de paniquer car ce sera peu exploiter et pas tout de suite mais ceux qui l'exploiteront auront tous de même un sacré avantage.

Comme dit dans le papier, il existe des techniques qui permettent de supprimer l'exception qui fait planter le programme, donc non le programme de plantera pas des millions de fois.

Aussi, il n'y pas pas besoin de dumper toute la mémoire car et la plupart des programmes (surtout natif) ont souvent des patterns d'allocations bien déterministe ce qui rend beaucoup plus rapide la recherche et l'analyse de la mémoire pour un programme malveillant. Bref, Meltdown n'est pas clairement pas impossible a mettre en œuvre, loin de la même. Pour rappel on a déjà eu Stuxnet qui consistait quand même a faire un virus qui reprogrammais les automates des centrifugeuses des centrales iraniennes pour ralentir leur programme nucléaire. Donc ça m'étonnerait que certaines organisation ne s'intéresse pas à cette faille qui leur laisse la porte ouverte a tout PC équipé d'un CPU Intel de moins de 10 ans.

[liberal1]

Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit

Si les données bancaires sont dans des fichiers appartenant à l'utilisateur, alors il n'y a aucune faille à exploiter! Sauf s'ils sont chiffrés, et là il faut attendre que l'utilisateur entre le mdp.

Ce schéma n'a rigoureusement aucun sens.

Tout l'article a besoin d'être refait.

Si tu parles de Meltdown, j'ai pas l'impression que la faille soit dur a exploiter, il suffit juste d'un programme en user-space. Si tu as des données un tant soit peu importante c'est stupide de ne pas appliquer le patch.

C'est largement pire, tu n'as pas besoin d'avoir le droit d'exécuter du code en mode user. Tu as juste besoin d'avoir la possibilité de faire exécuter une fonction (en Javascript ou n'importe quoi) par un programme correct (un navigateur sans bug ou n'importe quoi), qui soit performant (qui compile le code).

Je trouve cela vertigineux.

[joublie]

Il a bien fait de revendre ses actions, le big boss d'Intel, même si - bien sûr - cela n'a rien à voir. Il pourrait même postuler pour devenir ministre du travail en France...
Blague à part, je me pose des questions sur les brevets et les passages de salariés d'une entreprise à une autre (Intel, AMD, ARM). Comment cette faille se retrouve-t-elle dans trois entreprises : point de brevet déposé dans cette affaire ?

Correction : et IBM aussi ?

[arond]

Il a bien fait de revendre ses actions, le big boss d'Intel, même si - bien sûr - cela n'a rien à voir. Il pourrait même postuler pour devenir ministre du travail en France...
Blague à part, je me pose des questions sur les brevets et les passages de salariés d'une entreprise à une autre (Intel, AMD, ARM). Comment cette faille se retrouve-t-elle dans trois entreprises : point de brevet déposé dans cette affaire ?

Correction : et IBM aussi ?

Il semblerait que la faille repose sur la façon de fonctionner des processeurs pas sur le moyen de le faire.

Un peu comme si le paradigme objet avait une faille zéro day. Java/Php/C++ serait affecté pourtant ils ne se sont pas copiés

Si j'ai bien compris cet exploit repose sur la prédiction de résultat du CPU mais on peu pas désactivé cette feature ?

[Christophe]

Sous Windows, certains anti-virus sont incompatibles avec le correctif, provoquant un BSOD. Il semblerait que la mise à jour ne vous soit fournie que si votre antivirus est compatible (vérification d'une clé dans le registre)

Vérifiez que votre antivirus soit bien à jour (pas uniquement les définitions virales).

[Christophe]

Je pense que les failles reposent sur le dispositif de prédiction de branchement.

Le cpu fait de l'exécution spéculative avec un gain de performance en cas de succès et une perte en cas d’échec, mais globalement cela donne un gain de perfs. C'est pour cela que le code et les données doivent être alignés dans des pages.

Corrompre les caches du CPU donnera un résultat aléatoire, je pense que c’est le principe de fonctionnement des exploits de ces failles. Ces caches sont importants pour l'utilisation de la MMU, qui gère les droits d'accès aux pages mémoires.

Je pense que les patchs invalident les caches à des moments bien précis, ce qui fait perdre en perf.

[Invité]

Je ne sais pas si vous imaginez bien un WannaCry sauce meltdown-specter. Ce que je veux dire est que certains vont prendre de la dette ne pouvant patcher, ni même changer de proc. Et en face il se trouve déjà des scripts d'exploit et tutoriels accompagnés des outils et malware des agences américaines tombés entre les mains de pirates.
Pire que tout puisqu on y verra que du feu.

Ça pourrait faire très mal. Et je n'évoque que les pirates donc sans parler des agences gouvernementales et autres APT Lazarus.

[jlliagre]

Je pense que les failles reposent sur le dispositif de prédiction de branchement.

Les trois failles reposent sur l'exécution spéculative, ce qui est un peu différent de la prédiction de branchement.

Avec la prédiction de branchement, lorsqu'il va y avoir un test (du style if/then/else) le processeur va charger l'instruction qu'il pense avoir le plus de chances d'être la suivante.

Avec l'exécution spéculative, le CPU charge une instruction qu'il estime avoir bonne chance d'être exécutée mais en plus, il l'exécute vraiment.

Dans les deux cas, si l'hypothèse est infirmée, l'exécution reprend vers la bonne instruction à exécuter. En théorie, on revient dans le même état que celui ou l'on aurait été sans ces optimisations, mais en pratique, l'exécution spéculative a des effets de bord: la perte de données qui étaient auparavant en cache et la présence dans le cache de données qui n'y seraient pas allées autrement.

Il n'y a pas d'instructions qui permettent de lire directement les données placées en cache par les techniques précédentes mais il existe des moyens détournés sophistiqués pour le deviner. Celui qui est le plus souvent décrit consiste à mesurer le temps mis à charger le contenu d'une adresse mémoire. Si ce temps est "long", c'est que le processeur est bien allé chercher la donnée en RAM. Si ce temps est court, c'est que cette adresse viens déjà d'être lue. On a donc réussi à lire le contenu du cache alors qu'il n'existe pas de moyen direct de le faire.

Avec Meltdown, on peut lire la totalité de la mémoire du noyau. On ne peut pas directement écrire dans cette mémoire, mais ce qu'on y lit, par exemple des mots de passe en clair ou des clefs privées pourra être exploité pour facilement devenir root.

Le cpu fait de l'exécution spéculative avec un gain de performance en cas de succès et une perte en cas d’échec, mais globalement cela donne un gain de perfs.

Il n'y a pas vraiment de perte de performance en cas d'échec (la durée du rollback doit être infime). Le temps passé par le CPU à faire de l'exécution spéculative aurait sinon été perdu à ne rien faire.

Corrompre les caches du CPU donnera un résultat aléatoire, je pense que c’est le principe de fonctionnement des exploits de ces failles.

Il n'y a pas de corruption des caches, mais au contraire chargement de données valides mais "interdites" dans les caches. Invalider complètement les caches supprimerait le risque mais serait inacceptable en terme de performance. Il faut cent à deux cents fois plus de temps pour charger des données de la RAM par rapport au cache niveau 1, vingt fois plus que le cache niveau 2.

Ces caches sont importants pour l'utilisation de la MMU, qui gère les droits d'accès aux pages mémoires.

Je pense que les patchs invalident les caches à des moments bien précis, ce qui fait perdre en perf.

Les patches qui sont disponibles pour Windows, Linux et OS X mettent en place une séparation franche entre espace mémoire utilisateur et espace mémoire noyau, ce qui n'était pas le cas jusqu'ici. L'objectif est de contrer Meltdown (spécifique aux processeurs Intel) mais avec un impact sur les performances qui est sujet à controverse (entre non mesurable et 30% suivant l'utilisation du processeur).

Il existe aussi des patches pour les compilateurs qui modifient le code assembleur généré pour contrer certains types d'attaques en replaçant les appels par un "retpoline" (return trampoline) et des patches pour le microcode des CPUs

[Shol4891]

"La société affirme que cette vente d’actions n’était pas liée à la découverte de la faille en question, mais qu’elle faisait partie d’un programme de cession planifié."
C'est plausible

[Christian Olivier]

AMD pourrait vendre plus de CPU serveur dédiés au cloud computing
Après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel

Rappel des faits

Grâce aux précisions fournies par Google, on sait désormais que les vulnérabilités critiques touchant les CPU modernes, et probablement toute l’industrie des semi-conducteurs, affectent surtout les CPU x86 64-bits d’Intel. Mais ces failles de sécurité touchent aussi les CPU basés sur l’architecture ARM (Apple, Qualcomm, Samsung…) et Red Hat a prévenu que des CPU d’IBM sont également concernés.

Les chercheurs de Google ont découvert que la temporisation du cache de données des processeurs modernes peut être utilisée de manière abusive pour récupérer illégalement les informations sur un ordinateur. Cette fonctionnalité est utilisée par la plupart des processeurs modernes pour optimiser les performances, mais elle peut également occasionner de graves problèmes de sécurité.

Des attaquants peuvent en effet tirer parti de l’exécution spéculative pour exploiter des processus au niveau de l’espace utilisateur en contournant la MMU et lire le contenu de la mémoire du noyau d’un ordinateur qui en temps normal aurait dû leur être inaccessible.

Le problème étant matériel, c’est-à-dire qu’il concerne la partie non reconfigurable du processeur, il ne serait pas envisageable de recourir à un patch via microcode pour corriger toutes les variantes de cette faille de sécurité. Pour remédier efficacement à ce problème, il faut recourir à une technique d’isolation de la table de correspondance ou concevoir de nouveaux processeurs.

Meltdown et Spectre

Il existe trois variantes principales de la faille de sécurité qui exploite les mécanismes d’exécution spéculative des processeurs modernes : variante 1 (CVE-2017-5753), variante 2 (CVE-2017-5715), variante 3 (CVE-2017-5754 alias Meltdown). Google les a décrites en précisant leurs mécanismes d’action respectifs. Elles ont été baptisées Meltdown et Spectre à cause des attaques de type « side channel », « bounds check bypass » et « branch target injection » auxquelles elles exposent. Spectre correspond aux variantes 1 (bounds check bypass) et 2 (branch target injection) et expose aux types d’attaques spécifiques qui y sont relatifs, tandis que Meltdown n’est concerné que par les attaques de type « side channel ».

Meltdown casse les mécanismes d’isolation mémoire entre l’espace utilisateur et la mémoire noyau, permettant ainsi à un programme malveillant d’accéder à la mémoire vive de l’appareil. Spectre, pour sa part, brise la barrière entre les applications et permet d’obtenir des informations sensibles sur des applications en cours d’exécution, même si elles sont protégées. Ces vulnérabilités critiques affecteraient l’industrie des semi-conducteurs depuis au moins 1995.

La variante 1 affecte la quasi-totalité des CPU modernes. La variante 2 affecte surtout les processeurs d’Intel et d’ARM, alors que la variante 3 (Meltdown) touche de façon spécifique, pour le moment du moins, les processeurs d’Intel. Spectre est plus difficile à exploiter que Meltdown, mais est aussi plus difficile à patcher.

Le contexte actuel

Ces vulnérabilités critiques ne devraient pas pénaliser les particuliers et certains professionnels qui peuvent accepter d’utiliser leurs appareils même s’ils sont exposés à un risque avéré de piratage. Cependant, pour des acteurs opérant dans des industries aussi sensibles que celle du cloud, un tel danger et les risques auxquels il expose pourraient avoir des conséquences désastreuses. Certains experts estiment, d’ailleurs, qu’il faudra changer de processeurs ou carrément d’appareil pour être totalement protégé.

Lorsque de nouveaux processeurs exempts de la faille de sécurité décrite seront disponibles, les exploitants de serveurs concernés par ces vulnérabilités critiques devront faire un choix : remplacer les anciens équipements avec du nouveau matériel mieux sécurisé et probablement plus cher ou continuer de travailler avec l’ancien malgré les risques.

Les entreprises qui vont décider d’acquérir de nouveaux équipements vont probablement essayer de minimiser les risques en diversifiant les architectures sur lesquelles leurs activités critiques reposent. Compte tenu des performances attrayantes offertes par les derniers processeurs EPYC de la firme de SunnyVale et du fait que ses processeurs semblent, à l’heure actuelle, être les plus sûrs du marché, il ne serait pas surprenant d’assister à un regain de croissance au sein de l’activité Enterprise, Embedded et Semi-Custom d’AMD et au repositionnement de la société sur des marchés hautement stratégiques comme celui des puces serveur, notamment celles dédiées au Cloud Computing.

Le cas particulier d’AMD

AMD a récemment annoncé dans un communiqué que « l’ampleur de la menace et la nature des mesures à adopter concernant les trois variantes diffèrent selon le fabricant de microprocesseurs considéré, et AMD n’est pas sensible aux trois variantes ». La firme de SunnyVale soutient que le risque serait quasi nul pour ses processeurs x86 64-bits les plus récents et les recherches menées par Google tendent à confirmer cette annonce. En effet, Project Zero, le groupe de sécurité de la firme de Mountain View à l’origine de ces révélations a démontré que les puces conçues par AMD ne sont concernées que par la variante 1 de la faille de sécurité dont il est question.

Durant la semaine qui a suivi l’annonce de ces vulnérabilités critiques, les investisseurs se sont rués sur les actions du groupe AMD, alors que ceux qui possédaient des actions chez Intel ont plutôt commencé à s’en débarrasser. C’est probablement le même réflexe qui a animé le PDG d’Intel, Brian Krzanich, lorsqu’il a décidé de vendre les actions qu’il possédait chez Intel pour 24 millions USD après que la compagnie a été informée par Google des vulnérabilités majeures affectant ses puces.

Les actions d’AMD ont connu une hausse de 10,4 % pendant les deux premiers jours qui ont suivi la publication de ce rapport, alors que les actions d’Intel ont baissé de 5,2 % sur la même période, faisant ainsi perdre environ 11,3 milliards USD aux actionnaires de la firme de Santa Clara.

L’avenir du marché des CPU pour serveurs

« Les clients opérant sur le long terme pourraient être plus motivés à trouver des alternatives chez AMD et éventuellement ARM pour diversifier les risques architecturaux », a écrit l’analyste de Bank of America Merrill Lynch, Vivek Arya, avant d’ajouter que « tout porte à croire qu'AMD sera le principal bénéficiaire » de cette situation.

AMD pourrait profiter de cette situation et en retirer « un avantage marketing conséquent compte tenu des différences d’architectures et du risque de vulnérabilité négligeable » qui caractérisent ses puces pour le moment, a déclaré Vijay Rakesh, analyste chez Mizuho Securities. Cela permettra à la société technologique américaine AMD de tirer son épingle du jeu et de regagner du terrain face à Intel sur le marché des serveurs, un marché archidominé par la firme de Santa Clara. Rakesh a noté qu’Intel détient 99 % du marché des processeurs destinés aux datacenters.

« L’annonce des problèmes de sécurité affectant les processeurs d’Intel et la dégradation potentielle des performances qui pourrait résulter de leurs corrections arrivent à un moment inopportun, car Intel subit actuellement une forte pression de la part de son redoutable concurrent, AMD », écrit Fred Hickey, rédacteur chez High Tech Strategist. En outre, « la nouvelle gamme de processeurs AMD représente, pour la première fois depuis de nombreuses années, un sérieux challenger (depuis l’époque des processeurs Opteron de la marque) », a-t-il ajouté.

« Pour Intel, cela signifie probablement une perte des parts de marché (baisse des revenus) ainsi qu’une perte au niveau du contrôle des prix (marges brutes moindres) », a confié Hickey avant de souligner que « les nouvelles puces d’AMD ont déjà pris de l’ampleur et cette dynamique sera probablement amplifiée par les récentes divulgations au sujet des failles de sécurité. »

Source : CNBC

Et vous ?

Qu’en pensez-vous ?
AMD peut-elle tirer son épingle du jeu sur le marché des CPU serveur ?
Intel aurait-elle du souci à se faire ?

Voir aussi

Processeurs x86 pour PC : AMD aurait repris 10 % de parts de marché à Intel au premier trimestre 2017, grâce à ses processeurs Ryzen ?
AMD annonce des résultats financiers satisfaisants pour son troisième trimestre grâce aux performances de sa division Computing and Graphics

[Ryu2000]

AMD peut-elle tirer son épingle du jeu sur le marché des CPU serveur ?

Je ne sais pas, mais j’espère !
J'aime beaucoup AMD, les processeurs et les cartes mères sont moins chère.
La plupart des PC que je me suis monté avaient un processeur AMD.

En plus ils ont innové pour le grand public : processeur double cœur, processeur 64 bits, processeur 4 cœurs, etc.
De ce que je me rappelle les premiers processeurs 64 bits pour le grand public (2003) était des AMD et pareil pour les double cœurs (2004).

Par contre Intel est loin devant.
En gros 80% des ordinateurs sont équipé de processeurs Intel (statistique au pif).
Qu'AMD finisse par dépasser Intel ça m'étonnerait, mais AMD peut redevenir populaire (comme en 2004 ).

Intel aurait-elle du souci à se faire ?

Bof...
Il est toujours largement devant.
Des logiciels sont optimisés pour les processeurs Intel et pas les processeurs AMD.

Il y a quelques années j'avais testé Android Studio et l'émulateur par défaut ne fonctionnait qu'avec des processeurs Intel.

Pourvu qu'AMD gagne des parts de marché, c'est toujours bien la vraie concurrence.
AMD innove souvent en plus.

[athlon64]

C'est une aubaine pour AMD.

Oui, on a aussi d'autres fabricants comme Nvidia qui peuvent en profiter
Les entreprises vont aussi diversifier leur architecture et ne plus rester sur du matériel homogène

Google a trouvé les failles donc sont à même de mieux comprendre le problème et donc de le résoudre au mieux...

Oui ils doivent tous coopérer en plus avec les éditeurs D'OS , c'est d'abord une faille matérielle et l'architecture détaillée est détenue par intel.

je me demande si Google ne va pas se mettre à fabriquer ses propres processeurs, il pourrait même racheter un petit fabricant...

[AoCannaille]

je me demande si Google ne va pas se mettre à fabriquer ses propres processeurs, il pourrait même racheter un petit fabricant...

Ou un gros, ils en ont les moyens

[e101mk2]

Entre Intel Management Engine, Meltdown et Spectre, Intel bat des records.

Les entreprises vont ce mettre à trembler dès qu'ils vont entendre parler d'Intel...

[RyzenOC]

J'ai le sentiment qu'Intel délaisse de plus en plus la fabrication/conception de CPU x86... pour d'autre secteur engendre beaucoup moins d'investissement.

Entre l'architecture core qui 10ans, leur 10nm qui se fait attendre depuis déjà quelques années... (au CES Intel n'a pas dit 1 mots sur son 10nm... ce qui peut laisser penser que c'est une cata).
L'abandon des cpu atom qui signe la fin des puce ultra mobile d'intel et en parallèle la fabrication sur commande cpu ARM dans ces fonderies.

Intel ne fait plus évoluer sont architecture CPU.
La dernière évolution majeur d'intel pour l'architecture x86 c'est l'AVX512 qui date de 2013.

Pendant ce temps dans le reste du monde :
1) AMD lance Ryzen, une gamme de cpu qui offre un meilleur rapport qualité/prix qu'intel
2) MS lance des pc portable windows sous ARM
3) A la grande surprise générale, les asiatiques reviennent sur le marché du X86. Je parle pas d'AMD mais de VIA qui vas lancer cette années des cpu 4 et 8 cœurs x86 pour le grand publique.
En tous cas les cpu Zhaoxin peuvent être intéressant dans le milieu/bas de gamme si ils sont vendu pas cher.

En réponse fin 2017 Intel lance dans la foulé des I9 mal finit, lance une 8ieme génération 6 mois après la 7ieme sans innovation (si ce n'est de mettre un gpu vega d'amd dans leurs cpu...)
et les cannonlake se font toujours attendre... espérons que le 10nm d'intel apporte une baisse significative du TDP. Cannonlake basé sur l'architecture core avec évidement la faille Meldown.

Et l'ARM est tres néfaste pour le consommateur je m'explique :
Les machines ARM grand publique (smartphone, tablette ou pc portable/chromebook) sont des machines sans UEFI avec donc un driver spécifique pour booter.
Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez. Vous êtes emprisonné dans android ou dans windowsRT.
Je dirais même plus, vous êtes emprisonné dans une version spécifique de Android si Lineage OS supporte pas votre smartphone.

L'arm condamne Linux d'une certaine manière....
C'est pas l'architecture ARM le probleme, car j'ai des serveurs arm dans ma boite qui eux ont des UEFI et je peut booter une debian/centos arm dessus sans probleme.
Mais le probleme c'est bien les constructeurs grand publique, qui ne font et ne ferons jamais aucun effort pour implémenter un bios/uefi.

Pour vous donner un exemple, voyer le "bordel" pour booter sur un raspberry par exemple. Sa n'a rien a voir avec un pc je veut dire. Il faut utiliser une rom linux spécifique au raspberry. Y'a pas une distrib linux ARM générique qui marche sur toute les machines arm. Sur X86 par contre debian 32bits peut en théorie booter sur tous les pc x86 > 1995

[Christophe]

J'ai le sentiment qu'Intel délaisse de plus en plus la fabrication/conception de CPU x86... pour d'autre secteur engendre beaucoup moins d'investissement.

Pas impossible.

leur 10nm qui se fait attendre depuis déjà quelques années

On atteint peut-être les limites de faisabilité, mais j'avoue ne pas suivre de façon assidue ces évolutions.

Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez

Pourquoi ? c'est juste que le boot ne se fait pas de la même façon que sur x86 avec le bios ou l'UEFI. Il te faut un OS compatible.

Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez. Vous êtes emprisonné dans android ou dans windowsRT.
Je dirais même plus, vous êtes emprisonné dans une version spécifique de Android si Lineage OS supporte pas votre smartphone.

Ca c'est le constructeur qui décide. Au même titre que le secureboot UEFI, imposé par Microsoft pour bénéficier du logo Windows Ready complexifiera le boot sur Linux et empêchera même le boot d’anciennes versions Windows telles que Windows 7. LA version WindowsRT fonctionnant sur CPU ARM ne permet l’exécution que d'applications spécifiques, les applis win32 ne fonctionnent pas, d'où son echec.

C'est pas l'architecture ARM le probleme, car j'ai des serveurs arm dans ma boite qui eux ont des UEFI et je peut booter une debian/centos arm dessus sans probleme.

cf problème exposé ci-dessus, Debian refuse d'intégrer la clé Secureboot Microsoft, Debian reste installable en UEFI avec secureboot désactivé.

Les processeurs ARM prennent de l'ampleur au niveau serveur pour l'aspect basse consommation

[RyzenOC]

Pourquoi ? c'est juste que le boot ne se fait pas de la même façon que sur x86 avec le bios ou l'UEFI. Il te faut un OS compatible.

Ca c'est le constructeur qui décide. Au même titre que le secureboot UEFI, imposé par Microsoft pour bénéficier du logo Windows Ready complexifiera le boot sur Linux et empêchera même le boot d’anciennes versions Windows telles que Windows 7. LA version WindowsRT fonctionnant sur CPU ARM ne permet l’exécution que d'applications spécifiques, les applis win32 ne fonctionnent pas, d'où son echec.

Oui c'est ce que j'ai dit :

Mais le probleme c'est bien les constructeurs grand publique, qui ne font et ne ferons jamais aucun effort pour implémenter un bios/uefi.

Et en théorie vous avez raison...
Dans la pratique vous savez pertinemment que le constructeur décidera de rien faire... si les constructeurs ne le font pas sur les smartphones et les tablettes je vois pourquoi ils le feraient sur des pc arm.
On en aura de toute manière la confirmation quand les 1ere machines arriverons (Q1 2018)

et même si les constructeurs publie leurs driver de boot (on peut toujours rêver), au final sa revient à dire que faudra une iso de linux pour chaque machine.... une Ubuntu raspberry sera incompatible avec un pc arm sous un S835, donc ubuntu devra fournir 2 version différente.
Maintenant imaginer avec 100 modèles différents, puis 500 puis 1000

Pour vous en convaincre, je vous invite a regarder l'installation de linux sur une surface RT
Microsoft ne veut pas signer UEFI shim pour architecture ARM, mais l'a fait pour architectures Intel, c'est pour cela que le Secure Boot n'est pas un problème pour Linux sur PCs/ordinateurs portables/Surface Pro/...
Et au pire sur un pc classique, les bios/uefi peuvent désactiver SecureBoot voir émuler un bios pour faire tourner les vieux OS.

[liberal1]

Cette technique a ses avantages, mais elle présente également un risque non négligeable pour la sécurité, car aucune vérification de privilège n’est présente au niveau du noyau du système d'exploitation.

Le noyau n'a aucun rôle dans dedans. Propos absurde.

Ces processeurs disposent d’unités spécialisées dans la gestion de la mémoire (MMU) qui permettent de contrôler les accès qu’un CPU fait à la mémoire de l’ordinateur. Ils peuvent fonctionner suivant au moins deux modes de fonctionnement, dont un mode noyau qui n’impose pas de restrictions sur les instructions exécutées, et un mode utilisateur qui limite ce que peuvent faire les instructions.

C'est faux. Les limites s'appliquent, sauf évidemment qui ne concernent que les niveau utilisateur.

Habituellement, le système d’exploitation met en œuvre cette distinction en faisant fonctionner les autres programmes en mode utilisateur et en se réservant le mode noyau. Cette distinction entre espace utilisateur et espace noyau est à la base du contrôle d’accès qui empêche les instructions des applications de l’espace utilisateur d’accéder à une zone mémoire ne leur appartenant pas.

Faux. Une zone mémoire n'a pas de propriétaire.

On parle aussi de lecture d’une adresse mémoire non autorisée lorsque ce dysfonctionnement survient. Cette situation débouche rapidement sur une trappe du noyau et, en général, la fermeture du programme incriminé. Il faut noter que la trappe est déclenchée par une interruption matérielle

Encore faux. Les interruptions matérielles n'ont rien à voir avec cette histoire.

[transgohan]

Je ne sais pas si c'est un troll alors je vais joindre de la doc...

Trap : https://en.wikipedia.org/wiki/Trap_(computing)
C'est bien une interruption matérielle du CPU.

MMU : https://fr.wikipedia.org/wiki/Unité_de_gestion_mémoire
Donc oui chaque application n'a l'accès qu'à sa propre mémoire allouée, donc on peut parler de propriété.

CPU mode : https://en.wikipedia.org/wiki/CPU_modes
Des jeux d'instructions ne peuvent être exécutées qu'en mode noyau (ou superuser suvant le langage).

Cela infirme tes trois derniers commentaires...
Je ne m'avancerai pas pour le premier n'ayant pas compris où tu voulais en venir.

[liberal1]

Je ne sais pas si c'est un troll alors je vais joindre de la doc...

Non, c'est de la compétence (basique) en informatique. La mienne.

Trap : https://en.wikipedia.org/wiki/Trap_(computing)
C'est bien une interruption matérielle du CPU.

Non, rien à voir :

a type of synchronous interrupt

matériel se dit "hardware" en anglais, pas "synchronous"

MMU : https://fr.wikipedia.org/wiki/Unité_de_gestion_mémoire
Donc oui chaque application n'a l'accès qu'à sa propre mémoire allouée, donc on peut parler de propriété.

Chaque fils d'exécution (et pas "application" ce qui ne veut rien dire) n'a accès qu'à ce qui a été projeté dans l'espace mémoire du processus où il s'exécute. Aucun notion de "propriété". C'est un contre sens grave.

CPU mode : https://en.wikipedia.org/wiki/CPU_modes
Des jeux d'instructions ne peuvent être exécutées qu'en mode noyau

Certes. Et alors?

Tu n'as réfuté aucune de mes affirmations.

CPU mode : https://en.wikipedia.org/wiki/CPU_modes
mode noyau (ou superuser suvant le langage).

Il n'y a pas de "mode superuser".