diff options
Diffstat (limited to 'i18n/fr_FR/www')
| -rw-r--r-- | i18n/fr_FR/www/faq.md | 1210 |
1 files changed, 632 insertions, 578 deletions
diff --git a/i18n/fr_FR/www/faq.md b/i18n/fr_FR/www/faq.md index be540033..cbbdc2c0 100644 --- a/i18n/fr_FR/www/faq.md +++ b/i18n/fr_FR/www/faq.md @@ -346,8 +346,7 @@ laquelle le micrologiciel de démarrage est stocké) ne peut pas affecter la clà publique stockée sur le processeur. Les versions 4.0 et au-delà de la ME (Intel 4 Series et jeux de puces d'après) -incluent une application de la ME pour ***la -[DRM](https://defectivebydesign.org/what_is_drm_digital_restrictions_management) de l'audio et de la +incluent une application de la ME pour ***la [DRM](https://defectivebydesign.org/what_is_drm_digital_restrictions_management) de l'audio et de la vidéo***, appelé "Protected Audio Video Path" (PAVP). La ME reçoit du système d'exploitation hôte un flux média chiffré et une clé chiffré, déchiffre la clé, et envoie la clé déchiffré à la carte graphique, qui ensuite déchiffre @@ -363,671 +362,726 @@ démontre les capacités d'omnipotences de la ME; ce matériel et son micrologiciel propriétaire peut accéder et contrôler tout ce qui est dans la RAM et même ***tout ce qui est montré sur l'écran***. - - -In this usage, the PAVP application directly controls the graphics that -appear on the PC's screen in a way that the host OS cannot detect. ME -firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7 -(Sandy Bridge) CPUs replaces PAVP with a similar DRM application called -"Intel Insider". Like the AMT application, these DRM applications, -which in themselves are defective by design, demonstrate the omnipotent -capabilities of the ME: this hardware and its proprietary firmware can -access and control everything that is in RAM and even ***everything that -is shown on the screen***. - -The Intel Management Engine with its proprietary firmware has complete -access to and control over the PC: it can power on or shut down the PC, -read all open files, examine all running applications, track all keys -pressed and mouse movements, and even capture or display images on the -screen. And it has a network interface that is demonstrably insecure, -which can allow an attacker on the network to inject rootkits that -completely compromise the PC and can report to the attacker all -activities performed on the PC. It is a threat to freedom, security, and -privacy that can't be ignored. - -Before version 6.0 (that is, on systems from 2008/2009 and earlier), the -ME can be disabled by setting a couple of values in the SPI flash -memory. The ME firmware can then be removed entirely from the flash -memory space. libreboot [does this](../docs/hardware/gm45_remove_me.md) on -the Intel 4 Series systems that it supports, such as the [Libreboot -X200](../docs/install/x200_external.md) and [Libreboot -T400](../docs/install/t400_external.md). ME firmware versions 6.0 and -later, which are found on all systems with an Intel Core i3/i5/i7 CPU -and a PCH, include "ME Ignition" firmware that performs some hardware -initialization and power management. If the ME's boot ROM does not find -in the SPI flash memory an ME firmware manifest with a valid Intel -signature, the whole PC will shut down after 30 minutes. - -Due to the signature verification, developing free replacement firmware -for the ME is basically impossible. The only entity capable of replacing -the ME firmware is Intel. As previously stated, the ME firmware includes -proprietary code licensed from third parties, so Intel couldn't release -the source code even if they wanted to. And even if they developed -completely new ME firmware without third-party proprietary code and -released its source code, the ME's boot ROM would reject any modified -firmware that isn't signed by Intel. Thus, the ME firmware is both -hopelessly proprietary and "tivoized". - -**In summary, the Intel Management Engine and its applications are a -backdoor with total access to and control over the rest of the PC. The -ME is a threat to freedom, security, and privacy, and the libreboot -project strongly recommends avoiding it entirely. Since recent versions -of it can't be removed, this means avoiding all recent generations of -Intel hardware.** - -More information about the Management Engine can be found on various Web -sites, including [me.bios.io](http://me.bios.io/Main_Page), -[unhuffme](http://io.netgarage.org/me/), [coreboot -wiki](http://www.coreboot.org/Intel_Management_Engine), and -[Wikipedia](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology). -The book ***[Platform Embedded Security Technology -Revealed](https://www.apress.com/9781430265719)*** describes in great -detail the ME's hardware architecture and firmware application modules. - -If you're stuck with the ME (non-libreboot system), you might find this -interesting: +L' "Intel Management Engine" avec son micrologiciel propriétaire a un accés et +un contrôle complet sur le PC: il peut allumer ou éteindre le PC, lire toutes +les fichiers ouverts, examiner toutes les applications en cours d'exéution, +traquer toutes les touches pressées et mouvements de souris, et même faire des +captures ou montrer des images sur l'écran. +Et elle a une interface réseau qui est démontrée non sécurisée, qui peut +permettre un attaquant sur le réseau d'injecter des maliciels furtifs qui +peuvent complétement compromettre le PC et reporter toutes les activités ayant +lieu sur le PC à l'attaquant. C'est une menace à la liberté, sécurité et la +confidentialité qui ne peut pas être ignorée. + +Avant la version 6.0 (c'est à dire, sur les systèmes de 2008/2009 et plus +tôt), la ME peut être désactivée en configurant quelques valeurs dans la +mémoire flash SPI. Le micrologiciel de la ME peut être ensuite entiérement +enlevé de l'espace mémoire de la puce. libreboot [le +fait](../docs/hardware/gm45_remove_me.md) sur les systèmes avec Intel 4 Series +qu'il supporte, tel que le [Libreboot X200](../docs/install/x200_external.md) +et [Libreboot T400](../docs/install/t400_external.md). Le micrologiciel de la +ME version 6.0 et après, qui est trouvé sur tout système avec un processeur +Intel Core i3/i5/i7 et un PCH, inclut le micrologiciel "ME Ignition" qui +enclenche quelques initialisations matérielle et la gestion de l'alimentation. +Si la ROM de démarrage de la ME ne trouve pas dans la mémoire flash SPI un +manifeste de micrologiciel de la ME avec une signature d'Intel valide, le pc +tout entier s'éteindra après 30 minutes. + +Dû à la vérification de la signature, développer un micrologiciel de +remplacement libre de la ME est basiquement impossible. La seule entité +capabll e de remplacer le micrologiciel ME est Intel. Comme déclaré +auparavant, le micrologiciel de la ME inclut du code licensé par des parties +tierces, donc Intel ne pourrait même pas publier le code source si ils +voulaient. Et même s'ils développaient un micrologiciel de la ME complètement +nouveau, la ROM de démarrage de la ME rejecterait quelconque micrologiciel +modifié n'étant pas signé par Intel. +Donc, le micrologiciel de la ME est désespérement propriétaire et +[tivoisé](https://fr.wiktionary.org/wiki/tivo%C3%AFsation#Nom_commun). + +**En résumé, l'IME et ses applications sont une porte dérobée avec un accés +et un contrôle total sur le reste du PC. La ME est une menace à la liberté, +sécurité, la confidentialité et le projet libreboot recommande fortement de +l'éviter complètement. Puisque les versions récentes ne peuvent pas être +enlevées, ça veut dire éviter toutes générations récentes du matériel Intel.** + +Plus d'informations à propos de la ME peuvent être trouvées sur de nombreux +sites webs, incluant : + * [me.bios.io](http://me.bios.io/Main_Page) + * [unhuffme](http://io.netgarage.org/me/) + * [wiki de coreboot](http://www.coreboot.org/Intel_Management_Engine) + * [Wikipedia](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology) + + +Le livre ***[Platform Embedded Security Technology Revealed](https://www.apress.com/9781430265719)*** +décrit en grand détail l'architecture matérielle de la ME et des modules +applications du micrologiciel. + +Si vous êtes bloqué avec la ME (système non-libreboot), vous pourrez peut-être +trouver cela intéressant: <http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html> -Also see (effort to disable the ME): +Voyez aussi (efforts pour désactiver la ME): <https://www.coreboot.org/pipermail/coreboot/2016-November/082331.html> -- look at the whole thread - -### Firmware Support Package (FSP) {#fsp} - -On all recent Intel systems, coreboot support has revolved around -integrating a blob (for each system) called the *FSP* (firmware support -package), which handles all of the hardware initialization, including -memory and CPU initialization. Reverse engineering and replacing this -blob is almost impossible, due to how complex it is. Even for the most -skilled developer, it would take years to replace. Intel distributes -this blob to firmware developers, without source. - -Since the FSP is responsible for the early hardware initialization, that -means it also handles SMM (System Management Mode). This is a special -mode that operates below the operating system level. **It's possible -that rootkits could be implemented there, which could perform a number -of attacks on the user (the list is endless). Any Intel system that has -the proprietary FSP blob cannot be trusted at all.** In fact, several -SMM rootkits have been demonstrated in the wild (use a search engine to -find them). - -### CPU microcode updates {#microcode} - -All modern x86 CPUs (from Intel and AMD) use what is called *microcode*. -CPUs are extremely complex, and difficult to get right, so the circuitry -is designed in a very generic way, where only basic instructions are -handled in hardware. Most of the instruction set is implemented using -microcode, which is low-level software running inside the CPU that can -specify how the circuitry is to be used, for each instruction. The -built-in microcode is part of the hardware, and read-only. Both the -circuitry and the microcode can have bugs, which could cause reliability -issues. - -Microcode *updates* are proprietary blobs, uploaded to the CPU at boot -time, which patches the built-in microcode and disables buggy parts of -the CPU to improve reliability. In the past, these updates were handled -by the operating system kernel, but on all recent systems it is the boot -firmware that must perform this task. Coreboot does distribute microcode -updates for Intel and AMD CPUs, but libreboot cannot, because the whole -point of libreboot is to be 100% [free -software](https://www.gnu.org/philosophy/free-sw.html). - -On some older Intel CPUs, it is possible to exclude the microcode -updates and not have any reliability issues in practise. All current -libreboot systems work without microcode updates (otherwise, they -wouldn't be supported in libreboot). However, all modern Intel CPUs -require the microcode updates, otherwise the system will not boot at -all, or it will be extremely unstable (memory corruption, for example). - -Intel CPU microcode updates are *signed*, which means that you could not -even run a modified version, even if you had the source code. If you try -to upload your own modified updates, the CPU will reject them. - -The microcode updates alter the way instructions behave on the CPU. That -means they affect the way the CPU works, in a very fundamental way. That -makes it software. The updates are proprietary, and are software, so we -exclude them from libreboot. The microcode built into the CPU already is -not so much of an issue, since we can't change it anyway (it's -read-only). - -### Intel is uncooperative - -For years, coreboot has been struggling against Intel. Intel has been -shown to be extremely uncooperative in general. Many coreboot -developers, and companies, have tried to get Intel to cooperate; namely, -releasing source code for the firmware components. Even Google, which -sells millions of *chromebooks* (coreboot preinstalled) have been unable -to persuade them. - -Even when Intel does cooperate, they still don't provide source code. -They might provide limited information (datasheets) under strict -corporate NDA (non-disclosure agreement), but even that is not -guaranteed. Even ODMs and IBVs can't get source code from Intel, in -most cases (they will just integrate the blobs that Intel provides). - -Recent Intel graphics chipsets also [require firmware -blobs](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1). - -Intel is [only going to get -worse](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Gfx-GuC-SLPC) -when it comes to user freedom. Libreboot has no support recent Intel -platforms, precisely because of the problems described above. The only -way to solve this is to get Intel to change their policies and to be -more friendly to the [free -software](https://www.gnu.org/philosophy/free-sw.html) community. -Reverse engineering won't solve anything long-term, unfortunately, but -we need to keep doing it anyway. Moving forward, Intel hardware is a -non-option unless a radical change happens within Intel. - -**Basically, all Intel hardware from year 2010 and beyond will never be -supported by libreboot. The libreboot project is actively ignoring all -modern Intel hardware at this point, and focusing on alternative -platforms.** - -Why is the latest AMD hardware unsupported in libreboot? {#amd} + +### Paquetage de support micrologiciel (Firmware Support Package, FSP) {#fsp} + +Sur tout les systèmes Intel récents, le support de coreboot tourne autour de +l'intégration d'un blob (pour chaque système) appelé le *FSP* (firmware +support package), qui s'occupe de toute l'initialisation matérielle, incluant +la mémoire et l'initialisation du processeur. Déconstruire et remplacer ce +blob est presque impossible à la vue de sa complexité. Même pour le +développeur le plus talentueux, ça prendrait des années à remplacer. +Intel distribue ce blob aux développeurs de micrologiciels, sans le code +source. + +Puisque le FSP est responsable de l'initialisation matérielle précoce, ça veut +que ça gère aussi SMM (System Management Mode <=> Mode d'Administration +Système). C'est un mode spécial qui opère à un niveau en dessous le système +d'exploitation. **Il est possible que des rootkits soit implémentés ici, qui +pourrait lancer des attaques sur l'utilisateur (et la liste est sans fin). +Tout système Intel qui a le blob FSP propriétaire ne peut pas être digne de +confiance**. +D'ailleurs, quelques rootkits SMM se sont manifestés dans la jungle d'Internet +(utilisez un moteur de recherche pour les trouver). + +### Mises à jour du microcode du processeur {#microcode} + +Tout les processeurs modernes (d'Intel et AMD) d'architecte x86 utilise ce +qu'on appele le *microcode*. Les processeurs sont extremement complexe et +difficule a bien concevoir, donc la circuiterie est conçue d'une manière très +générique, où seulement les instructions basiques sont gérés dans le +matériel. La majorité du jeu d'instructions est implémenté via le microcode, +qui est du logiciel bas-niveau s'exéutant dans le processeur pouvant spécifier +comment la circuiterie doit être utilisée, pour chaque instruction. Le +microcode embarqué fait partie du matériel, et en mode lecture seulement. Le +microcode et la circuiterie peuvent avoir des bogues, ce qui peut causer des +problèmes de stabilité. + +Les *mises à jour* du microcode sont des blobs propriétaires, téléversé dans +le processeur pendant le démarrage, qui rustinent le microcode embarqué et +désactive les parties boguées du processeur pour améliorer la stabilité. +Avant, ces mises à jour étaient gérées par le kernel du système +d'exploitation, mais dans tout les systèmes récents c'est le micrologiciel de +démarrage qui doit s'occuper de ça. Coreboot distribue des mises à jour du +microcode pour les processeurs Intel et AMD, mais libreboot ne peut pas, parce +que le but de libreboot est d'être 100% [logiciel +libre](https://www.gnu.org/philosophy/free-sw.fr.html). + +Sur certains processeurs Intel plus vieux, il est possible d'exclure les mises +à jour du microcode et de n'avoir aucun problèmes de stabilité en pratique. +Tout les systèmes libreboot actuels marche sans les mises à jour du microcode +(sinon, ils ne seraient pas supportés dans libreboot). Cependant, tout +processeur Intel moderne nécessite une mise à jour du microcode, sinon le +système ne démarrera pas du tout, et sera extrêmement instable (corruption de +la mémoire, par exemple). + +Les mises à jour du microcode des processeurs Intel sont *signés*, ce qui veut +dire vous ne pourriez même pas exécuter une version modifiée, même si vous +avez le code source. Si vous essayez de téléverser vos propres mise à jour +modifiée, le processeur les rejétera. + +Les mises à jour du microcode altèrent la façon dont les instructions se +comportent sur le processeurs. Ça veut dire qu'elles peuvent affecter la façon +dont le processeur fonctionne de manière fondamentale. C'est ce en fait un +logiciel. Les mises à jour sont propriétaires, et sont des logiciels, donc +nous les excluons de libreboot. Le microcode compilé dans le processeur n'est +pas tellement un problème, puisque on ne peut pas le changer de toute façon +(il est en lecture seule). + +### Intel n'est pas coopératif + +Depuis des années, coreboot a du mal contre Intel. Intel s'est montré +extremement non coopératif en général. Beaucoup de développeurs de Coreboot, +et d'entreprises, ont tenté d'amener Intel à coopérer; en particulier, de +publier le code source de composants micrologiciel. Même Google, qui vend des +millions de *chrombebook* (avec coreboot préinstallé) ont été incapables de +les persuader. + +Même quand Intel coopére, ils ne fournissent toujours pas de codes sources. +Ils peuvent fournir des informations limitées (fiches techniques) sous un +accord de non-divulgation d'entreprise strict (appelé aussi NDA, "non +disclosure agreement"), mais même cela n'est pas garanti. +Même les [ODMs](https://fr.wikipedia.org/wiki/Original_Design_Manufacturer) +et IBVs ne peuvent pas recevoir le code source de la part d'Intel, dans la +majorité des cas (ils intégreront juste les blobs qu'Intel fournissent). + +Par ailleurs, les jeux de puces graphiques d'Intel récents [nécessite des +blobs +micrologiciels](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1) + +Intel va [uniquement devenir pire](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Gfx-GuC-SLPC) +en ce qui concerne la liberté de l'utilisateur. Libreboot ne supporte pas les +plateformes Intel récentes, précisément à cause des problèmes décris +au-dessus. La seule façon de régler cela est de faire qu'Intel change ses +politiques et soit plus amical à la communauté du [logiciel + libre](https://www.gnu.org/philosophy/free-sw.fr.html). +L'ingénérie inversée ne réglera rien sur le long terme malheuresement, mais +nous devons continuer de le faire de toute façon. En avançant, le matériel +Intel n'est pas une option à moins qu'un changement radical se passe à +l'intérieur d'Intel. + +**Basiquement, tout matériel de l'année 2010 et au-delà ne sera jamais +supporté par libreboot. Le project libreboot ignore activement tout matériel +Intel moderne à ce point, et se concentre sur des plateformes alternatives.** + +Pourquoi le matériel d'AMD récent n'est pas supporté dans Libreboot? {#amd} ---------------------------------------------------------------------------- -It is extremely unlikely that any post-2013 AMD hardware will ever be -supported in libreboot, due to severe security and freedom issues; so -severe, that *the libreboot project recommends avoiding all modern AMD -hardware. If you have an AMD based system affected by the problems -described below, then you should get rid of it as soon as possible*. The -main issues are as follows: - -[We call on AMD to release source code and specs for the new AMD Ryzen -platforms! We call on the community to put pressure on AMD. Click here -to read more](amd-libre.md) - -### AMD Platform Security Processor (PSP) - -This is basically AMD's own version of the [Intel Management -Engine](#intelme). It has all of the same basic security and freedom -issues, although the implementation is wildly different. - -The Platform Security Processor (PSP) is built in on all Family 16h + -systems (basically anything post-2013), and controls the main x86 core -startup. PSP firmware is cryptographically signed with a strong key -similar to the Intel ME. If the PSP firmware is not present, or if the -AMD signing key is not present, the x86 cores will not be released from -reset, rendering the system inoperable. - -The PSP is an ARM core with TrustZone technology, built onto the main -CPU die. As such, it has the ability to hide its own program code, -scratch RAM, and any data it may have taken and stored from the -lesser-privileged x86 system RAM (kernel encryption keys, login data, -browsing history, keystrokes, who knows!). To make matters worse, the -PSP theoretically has access to the entire system memory space (AMD -either will not or cannot deny this, and it would seem to be required to -allow the DRM "features" to work as intended), which means that it has -at minimum MMIO-based access to the network controllers and any other -PCI/PCIe peripherals installed on the system. - -In theory any malicious entity with access to the AMD signing key would -be able to install persistent malware that could not be eradicated -without an external flasher and a known good PSP image. Furthermore, -multiple security vulnerabilities have been demonstrated in AMD firmware -in the past, and there is every reason to assume one or more zero day -vulnerabilities are lurking in the PSP firmware. Given the extreme -privilege level (ring -2 or ring -3) of the PSP, said vulnerabilities -would have the ability to remotely monitor and control any PSP enabled -machine completely outside of the user's knowledge. - -Much like with the Intel Boot Guard (an application of the Intel -Management Engine), AMD's PSP can also act as a tyrant by checking -signatures on any boot firmware that you flash, making replacement boot -firmware (e.g. libreboot, coreboot) impossible on some boards. Early -anecdotal reports indicate that AMD's boot guard counterpart will be -used on most OEM hardware, disabled only on so-called "enthusiast" -CPUs. - -### AMD IMC firmware - -Read <https://www.coreboot.org/AMD_IMC>. - -### AMD SMU firmware +Il est extrêmement improbable que n'importe quel matériel d'après 2013 sera +supporté dans libreboot, à cause de problèmes de sécurité et de liberté +sévères; si sévère, que *le projet libreboot recommande d'éviter tout matériel +AMD moderne. Si vous avez un machine sous AMD affecté par les problèmes +décris ci-dessous, alors vous devriez vous en débarasser dès que possible*. +Les problèmes principaux sont comme il suit: + +[Nous demandons à AMD de publier le code source et les spécifications pour les +nouvelles plateformes AMD Ryzen! Nous appelons la communauté à faire pression +sur AMD. Cliquez ici pour en savoir plus](amd-libre.md) + +### Processeur de Sécurité de la Plateforme AMD (PSP) + +C'est basiquement la version de l'[Intel Management Engine](#intelme) propre à +AMD. Elle a tous les mêmes problèmes basiques de sécurité et de liberté, bien +que l'implémentation est radicalement différente. + +Le Processeur de Sécurité de la Plateforme (PSP ou "Platform Security +Processor") est embarqué dans tout les systèmes Family 16h+ (basiquement tout +ce que AMD a produit après 2013), et contrôle le démarrage de l'architecture +x86. +Le micrologiciel PSP est signé cryptographiquement avec une clé robuste +similaire à l'IME. Si le micrologiciel de la PSP n'est pas présent, ou si la clé de +signature d'AMD n'est pas présente, les coeurs d'architecture x86 ne seront +pas libérés de la réinitialisation, rendant le système inopérant. + +La PSP est un coeur ARM avec la technologie TrustZone, embarqué dans le *die* +(circuit intégré) du processeur. Alors donc, il a la possibilité de cacher le +code de son propre programme, gratter dans la RAM, et n'importe quelle données +il aurait pu prendre et stocker depuis la RAM moins privilégié du système x86 +(clés de chiffrement du kernel, données d'authentification, historique de +recherche, touches tapées, qui sait!). +Histoire d'empirer les tracas, le PSP a théoriquement accés à l'entièreté de +la mémoire système (AMD soit reniera ou ne pourra renier cela, et ça semble +être nécessaire pour permettre aux "fonctionnalités" de la DRM de marcher +comme prévues), ce qui veut dire qu'au minimum il a un accés basée MMIO aux +contrôleurs réseaux et n'importe quels autres périphériques PCI/PCIe installés +sur le système. + +En théorie n'importe quel entité malveillante avec un accés à la clé de +signature d'AMD serait capable d'installer des maliciels persistants qui ne +pourrait pas être éradiqués sans un flasheur externe et une image saine PSP. +Plus encore, de multiples failles de sécurité ont été démontrée dans le +micrologiciel d'AMD par le passé, et il y a toute les raisons d'assumer qu'une +ou plusieurs failles 'jour zéro' traînent dans le micrologiciel du PSP. É +tant donnée le privilège extrême (ring -2 ou -3) du PSP, lesdites +vulnérabilitées auraient la capacité d'observer et de contrôler n'importe +qu'elle machine avec PSP activé, sans que l'utilisateur s'en aperçoive. + +Comme avec l'Intel Boot Guard (Gardien de Démarrage Intel, une application de +l'Intel Management Engine), le PSP d'AMD peut aussi agir comme un tyrant en +vérifiant la signature sur n'importe quel micrologiciel de démarrage que vous +flashez, rendant le remplacement du micrologiciel de démarrage (p.ex par +libreboot, coreboot) impossible sur certaines cartes mères. +Des rapports anecdotiques précoces indiquent que la contrepartie du gardien de +démarrage d'AMD sera utilisé dans la majorité des matériels manufactureur, +désactivé seulement sur les processeurs pour 'enthousiaste'. + +### Micrologiciel IMC d'AMD + +Lisez <https://www.coreboot.org/AMD_IMC>. + +### Micrologiciel SMU d'AMD + +Prend en charge la gestion de l'alimentation des périphériques PCIe (sans ça, +votre ordinateur portable ne marchera pas correctement) et quelques autres +fonctionnalités concernant la gestion de l'alimentation. + +Le micrologiciel est signé, bien que sur du matériel AMD plus vieux c'est une +clé symmétrique, ce qui veut dire qu'avec l'accés à celle-ci (si elle a +fuité) vous pourriez signer votre propre version modifiée du micrologiciel et +l'exécuter. Handles some power management for PCIe devices (without this, your laptop will not work properly) and several other power management -related features. - -The firmware is signed, although on older AMD hardware it is a symmetric -key, which means that with access to the key (if leaked) you could sign -your own modified version and run it. Rudolf Marek (coreboot hacker) -found out how to extract this key [in this video -demonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek), -and based on this work, Damien Zammit (another coreboot hacker) -[partially replaced it](https://github.com/zamaudio/smutool/) with free -firmware, but on the relevant system (ASUS F2A85-M) there were still -other blobs present (Video BIOS, and others) preventing the hardware -from being supported in libreboot. - -### AMD AGESA firmware - -This is responsible for virtually all core hardware initialization on -modern AMD systems. In 2011, AMD started cooperating with the coreboot -project, releasing this as source code under a free license. In 2014, -they stopped releasing source code and started releasing AGESA as binary -blobs instead. This makes AGESA now equivalent to [Intel FSP](#fsp). - -### AMD CPU microcode updates - -Read the Intel section -practically the same, though it was found with much later hardware in -AMD that you could run without microcode updates. It's unknown whether -the updates are needed on all AMD boards (depends on CPU). - -### AMD is incompetent (and uncooperative) - -AMD seemed like it was on the right track in 2011 when it started -cooperating with and releasing source code for several critical -components to the coreboot project. It was not to be. For so-called -economic reasons, they decided that it was not worth the time to invest -in the coreboot project anymore. - -For a company to go from being so good, to so bad, in just 3 years, -shows that something is seriously wrong with AMD. Like Intel, they do -not deserve your money. - -Given the current state of Intel hardware with the Management Engine, it -is our opinion that all performant x86 hardware newer than the AMD -Family 15h CPUs (on AMD's side) or anything post-2009 on Intel's side -is defective by design and cannot safely be used to store, transmit, or -process sensitive data. Sensitive data is any data in which a data -breach would cause significant economic harm to the entity which created -or was responsible for storing said data, so this would include banks, -credit card companies, or retailers (customer account records), in -addition to the "usual" engineering and software development firms. -This also affects whistleblowers, or anyone who needs actual privacy and -security. - -What *can* I use, then? {#whatcaniuse} +related features. Rudolf Marel (un hacker de chez Coreboot) a trouvé comment +extraire cette clé [dans cette vidéo de +démonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek), +et basé sur son travail, Damien Zammit (un autre hacker de chez Coreboot) [l'a +partiellement remplacé](https://github.com/zamaudio/smutool/) avec du +micrologiciel libre, mais sur le système concerné (ASUS F2A85-M) il y avait +encore d'autres blobs présents (Video BIOS, et autres) empêchant le matériel +d'être supporté dans libreboot. + +### Micrologiciel AGESA d'AMD + +Il est responsable pour virtuellement toute l'initialisation du coeur matériel +sur les systèmes AMD modernes. En 2011, AMD a commencé à coopérer avec le +projet coreboot, publiant son code source sous une licence libre. En 2014, ils +sont arrêté de publier du code source et au lieu de ça ont commencé à publier AGESA en tant +que blobs binaires. Désormais, cela rend l'AGESA équivalent au [FSP +d'Intel](#fsp). + +### Mises à jour du microcode des processeurs AMD + +Lisez la section Intel. +Pratiquement la même chose, bien que il a été découvert qu'avec du matériel +plus récent d'AMD ont pouvait marcher sans mises à jour du microcode. Il est +inconnu si oui ou non les mises à jours sont nécessaires sur toutes les cartes +mères AMD (dépend du CPU). + +### AMD est incompétent (et pas coopératif) + +AMD semblait sur le bon chemin en 2011 lorsqu'ils ont commencé à coopérer, +publiant le code source de quelques composants très importants au projet +coreboot. Ce n'était pas +fait pour durer. Pour des soi-disantes raisons économiques, ils ont décidé que +ça ne vallait plus la peine d'investir dans le projet coreboot. + +Quelque chose ne va sérieusement pas avec AMD pour qu'en 3 ans, une entreprise +évolue de si bonne à si mauvaise. Comme Intel, ils ne méritent pas votre +argent. + +Étant donné l'état actuel du matériel Intel avec la Management Engine, il est +de notre avis que tout matériel performant d'architecture x86 plus récent que +les processeurs AMD Family 15h ou quoi que ce soit après 2009 côté Intel est +défectueux dès la conception, et ne peut pas être utilisé pour stocker, +transmettre, où traiter des données sensibles. Les données sensibles est +n'importe quelle donnée qui, lors d'une fuite de données, pourrait provoquer +un dommage économique significatif à l'entité qui a créé ou était responsable +du stockage desdites données, cela incluerait alors les banques, entreprises +de cartes bleues, marchands (détails des comptes clients), en addition de +l'ingénérie habituelle et firmes de développement logiciel. +Ça touche aussi les lanceurs d'alertes, ou n'importe qui ayant besoin d'une +veritable confidentialité et sécurité. + +Qu'est ce que je *peux* utiliser, alors? {#whatcaniuse} ------------------------- -Libreboot has support for fam15h AMD hardware (~2012 gen) and some -older Intel platforms like Napa, Montevina, Eagle Lake, Lakeport (2004-2006). -We also have support for some -ARM chipsets (rk3288). On the Intel side, we're also interested in some -of the chipsets that use Atom CPUs (rebranded from older chipsets, -mostly using ich7-based southbridges). +Libreboot supporte le matériel AMD fam15h (génération ~2012) et d'autres +plateformes Intel plus vieilles comme Napa, Montevina, Eagle Lake, Lakeport +(2004-2006) et d'autres plateformes Intel plus vieilles comme Napa, Montevina, +Eagle Lake, Lakeport (2004-2006). -Will libreboot work on a ThinkPad T400 or T500 with an ATI GPU? +Nous supportons aussi quelques jeux de puces ARM (rk3288). Côté Intel, nous +sommes aussi interessé par certains jeux de puces qui utilisent des +processeurs Atom (modifié à partir de jeux de puces plus vieux, en utilisant +principalement des bus contrôleurs entrées/sorties basés ich7). + +Libreboot marchera t-il sur un ThinkPad T400 ou T500 avec une carte graphique ATI ? --------------------------------------------------------------------------------------------------- -Short answer: yes. These laptops also have an Intel GPU inside, which -libreboot uses. The ATI GPU is ignored by libreboot. +Réponse courte: oui. Ces ordinateurs portables ont aussi une carte graphique Intel +à l'intérieur, que libreboot utilise. La carte graphique ATI est ignorée par +libreboot. -These laptops use what is called *switchable graphics*, where it will -have both an Intel and ATI GPU. Coreboot will allow you to set (using -nvramtool) a parameter, specifying whether you would like to use Intel -or ATI. The ATI GPU lacks free native graphics initialization in -coreboot, unlike the Intel GPU. +Ces ordinateurs portables utilisent ce qu'on appelle des *graphiques +interchangeables*, où ils ont à la fois une carte graphique Intel et une ATI. +Coreboot vous permettra (en utilisant nvramtool) de définir un paramètre +indiquant si vous voulez utiliser une des deux, Intel ou ATI. Les cartes +graphiques ATI n'ont pas d'initialisation graphique libre dans coreboot, +contrairement aux cartes graphiques Intel. -Libreboot modifies coreboot, in such a way where this nvramtool setting -is ignored. Libreboot will just assume that you want to use the Intel -GPU. Therefore, the ATI GPU is completely disabled on these laptops. -Intel is used instead, with the free native graphics initialization -(VBIOS replacement) that exists in coreboot. +Libreboot modifie coreboot d'une telle façon que la configuration nvramtool +est ignoré. Libreboot assumera juste que vous voulez utiliser la carte +graphique Intel. Donc, la carte graphique ATI est complétement désactivée sur +ces ordinateurs portables. Intel est utilisé à la place, avec l'initialisation +native libre des graphiques (remplacement du VBIOS) qui existe dans coreboot. -Will desktop/server hardware be supported? +Est-ce que matériel bureau/serveur sera supporté? ------------------------------------------------------------------------ -Libreboot now supports desktop hardware: -[(see list)](../docs/hardware/#supported_desktops_x86/intel) -(with full native video initialization). - -A common issue with desktop hardware is the Video BIOS, when no onboard -video is present, since every video card has a different Video BIOS. -Onboard GPUs also require one, so those still have to be replaced with -free software (non-trivial task). Libreboot has to initialize the -graphics chipset, but most graphics cards lack a free Video BIOS for -this purpose. Some desktop motherboards supported in coreboot do have -onboard graphics chipsets, but these also require a proprietary Video -BIOS, in most cases. - -Hi, I have <insert random system here>, is it supported? +Libreboot supporte maitenant du matériel d'ordinateur de bureau: +[(voyez la liste)](../docs/hardware/#supported_desktops_x86/intel) +(avec l'initialisation complètement native de la vidéo). + +Un problème commun avec le matériel de bureau est le BIOS Vidéo, quand pas de +vidéo embarquée n'est présente, puisque chaque carte vidéo a un BIOS Vidéo +différent. +Les cartes graphiques embarquées en nécessite un aussi, donc cela ont encore a +être remplacés par du logiciel libre (tâche non triviale). Libreboot doit +initiliaser le jeu de puces graphique, mais la majorité des cartes graphiques +n'ont pas de BIOS Vidéo libre pour cela. Quelques cartes mères d'ordinateurs +de bureau supportés dans coreboot ont des jeux de puces graphiques intégrés, +mais ceux-ci nécessite aussi un BIOS Vidéo propriétaire, dans la majorité des +cas. + +Bonjour, j'ai <insérer système/carte mère/>, est ce que c'est supporté? -------------------------------------------------------------------------------------------------------- -Most likely not. First, you must consult coreboot's own hardware -compatibility list at <http://www.coreboot.org/Supported_Motherboards> -and, if it is supported, check whether it can run without any -proprietary blobs in the ROM image. If it can: wonderful! Libreboot can -support it, and you can add support for it. If not, then you will need -to figure out how to reverse engineer and replace (or remove) those -blobs that do still exist, in such a way where the system is still -usable in some defined way. - -For those systems where no coreboot support exists, you must first port -it to coreboot and, if it can then run without any blobs in the ROM -image, it can be added to libreboot. See: [Motherboard Porting -Guide](http://www.coreboot.org/Motherboard_Porting_Guide) (this is just -the tip of the iceberg!) - -Please note that board development should be done upstream (in coreboot) -and merged downstream (into libreboot). This is the correct way to do -it, and it is how the libreboot project is coordinated so as to avoid -too much forking of the coreboot source code. - -What about ARM? +Problablement pas. En premier, vous devez consulter la propre liste de +compatibilité matérielle de coreboot sur +<http://www.coreboot.org/Supported_Motherboards>, et si il est supporté, +vérifiez si oui ou non il peut marcher sans blobs propriétaires dans +l'imageROM. Si ça le peut: merveilleux! Libreboot peut le supporter, et vous +pouvez le rajouter à la liste. Sinon, alors vous aurez besoin de savoir +comment destructurer logiciellement et remplacer (ou enlever) ces blobs +existant encore, d'une telle façon que le système est encore utilisable. + +Pour ces systèmes où pas de support de coreboot existe, vous devez d'abord les +adapter pour coreboot et, si ça peut alors marcher sans aucun blobs dans +l'image ROM, il peut être ajouté à libreboot. Voyez [le guide d'adaption des +cartes mères](http://www.coreboot.org/Motherboard_Porting_Guide) (c'est juste +le bout de l'iceberg!) + +Notez silvouplaît que le développement des cartes mères devrait être fait en +amont (dans coreboot) et fusionné en aval (à l'intérieur de libreboot). C'est +la bonne façon de le faire, et c'est comment le projet libreboot est coordonné +pour éviter trop de branchage (fork) du code source de coreboot. + +Et à propos de l'ARM? ----------------------------------- -Libreboot has support for some ARM based laptops, using the *Rockchip -RK3288* SoC. Check the libreboot [hardware compatibility -list](../docs/hardware/#supported_list), for more information. +Libreboot supporte pour quelques ordinateurs portables basés ARM, utilisant le +SoC *Rockchip RK3288*. Vérifiez la [liste de compatibilité +matérielle](../docs/hardware/#supported_list) de +libreboot, pour plus d'informations. -General questions +Questions générales ================= -How do I install libreboot? +Comment j'installe libreboot? ------------------------------------------------------- -See [installation guide](docs/install/) +Voyez [le guide d'installation](docs/install/) -How do I program an SPI flash chip? +Comment je programme une puce flash SPI? --------------------------------------------------------------------------------- -SPI flash chips can be programmed with the [BeagleBone -Black](../docs/install/bbb_setup.md) or the [Raspberry +Les puces flash SPI peuvent être programmées avec le [BeagleBone +Black](../docs/install/bbb_setup.md) ou la [Raspberry Pi](../docs/install/rpi_setup.md). -It's possible to use a 16-pin SOIC test clip on an 8-pin SOIC chip, if you -align the pins properly. The connection is generally more sturdy. +Il est possible d'utiliser une puce de test SOIC à 16-pin sur une puce SOIC à +8-pin, si vous alignez les pins proprement. La connection est généralement +plus robuste. -How do I set a boot password? +Comment définir un mot de passe de démarrage? ------------------------------------------------------------------- -If you are using the GRUB payload, you can add a username and password -(salted, hashed) to your GRUB configuration that resides inside the -flash chip. The following guides (which also cover full disk encryption, -including the /boot/ directory) show how to set a boot password in GRUB: -[(Installing Debian or Devuan with FDE)](../docs/gnulinux/encrypted_debian.md) -and -[(Installing Parabola or Arch GNU+Linux-Libre, with FDE)](../docs/gnulinux/encrypted_parabola.md) +Si vous utilisez la charge utile GRUB, vous pouvez ajouter un utilisateur et +un mot de passe (hashé et 'salé') dans votre configuration GRUB qui réside à +l'intérieur de la puce flash. Les guides suivants (qui couvrent aussi le +chiffrement du disque en entier, incluant le répertoire /boot/) montrent +comment définir un mot de passe de démarrage dans GRUB: +[(Installer Debian ou Devuan avec FDE)](../docs/gnulinux/encrypted_debian.md) +et +[(Installer Parabola ou Arch GNU+Linux-libre, avec FDE)](../docs/gnulinux/encrypted_parabola.md) -How do I write-protect the flash chip? +NdT: FDE est un acronyme pour "Full Disk Encryption", c'est à dire le +chiffrement du disque tout entier. + +Comment est-ce que je protège en écriture la puce flash? ---------------------------------------------------------------------------- -By default, there is no write-protection on a libreboot system. This is -for usability reasons, because most people do not have easy access to an -external programmer for re-flashing their firmware, or they find it -inconvenient to use an external programmer. +Par défaut, il n'y a pas de protection en écriture sur un système libreboot. +C'est pour des raisons d'ergonomie, parce que la majorité des gens n'ont pas +accés à un programmeur externe pour le reflashage de leur micrologiciel, ou +ils trouvent que c'est inconvénient d'utiliser un programmeur externe. -On some systems, it is possible to write-protect the firmware, such that -it is rendered read-only at the OS level (external flashing is still -possible, using dedicated hardware). For example, on current GM45 -laptops (e.g. ThinkPad X200, T400), you can write-protect (see -[ICH9 gen utility](../docs/hardware/gm45_remove_me.html#ich9gen)). +Sur certains systèmes, il est possible de protéger en écriture le +micrologiciel, de tel sorte qu'il est en lecture seule au niveau du système +d'exploitation (le flashage externe est encorfe possible, en utilisant du +matériel dédicacé). Par exemple, sur les ordinateurs portables GM45 d'en +ce moment (p.ex ThinkPad X200, T400), vous pouvez protéger en écriture (voyez +l'[utilitaire ICH9 gen](../docs/hardware/gm45_remove_me.html#ich9gen)). -It's possible to write-protect on all libreboot systems, but the instructions -need to be written. The documentation is in the main git repository, so you are -welcome to submit patches adding these instructions. +Il est possible de protéger en écriture sur tout les systèmes libreboot, mais +les instructions/guides ont besoin d'être écris. La documentation est dans le +répertoire git principal, donc vous êtes bienvenus pour soumettre des patches +(rustines) ajoutant ces instructions. -How do I change the BIOS settings? +Comment je change les paramètres du BIOS? ------------------------------------------------------------------------ -Libreboot actually uses the [GRUB -payload](http://www.coreboot.org/GRUB2). More information about payloads -can be found at -[coreboot.org/Payloads](http://www.coreboot.org/Payloads). +Libreboot utilise en fait la [charge utile +GRUB](http://www.coreboot.org/GRUB2). Plus d'informations sur les charges +utiles peuvent être trouvées à +[coreboot.org/Payloads](http://www.coreboot.org/Payloads) -Libreboot inherits the modular payload concept from coreboot, which -means that pre-OS bare-metal *BIOS setup* programs are not very -practical. Coreboot (and libreboot) does include a utility called -*nvramtool*, which can be used to change some settings. You can find -nvramtool under *coreboot/util/nvramtool/*, in the libreboot source -archives. +Libreboot inhérite du concept modulaire des charges utiles de coreboot, ce qui +veut dire que les programmes de *configuration du BIOS* pré-système +d'exploitation sur machines "nues" ne sont pas très pratiques. +Coreboot (et libreboot) incluent un utilitaire appelé *nvramtool*, qui peut +être utilisé pour changer quelques paramtères. Vous pouvez trouver nvramtool +sous *coreboot/util/nvramtool*, dans les archives du code source de libreboot. -The *-a* option in nvramtool will list the available options, and *-w* -can be used to change them. Consult the nvramtool documentation on the -coreboot wiki for more information. +L'option *-a* de nvramtool listera les options disponibles, et *-w* peut être +utilisé pour les changer. Consultez la documentation de nvramtool sur le wiki +coreboot pour plus d'informations. -In practise, you don't need to change any of those settings, in most -cases. +En pratique, vous n'avez pas besoin de changer aucun de ces paramètres, dans +la majorité des cas. -Libreboot locks the CMOS table, to ensure consistent functionality for -all users. You can use: +Libreboot verouille la table CMOS, pour assurer une fonctionnalité consistante +pour tout les utilisateurs. Vous pouvez utiliser: $ nvramtool -C yourrom.rom -w somesetting=somevalue +Cela changera un paramètre par défaut à l'intérieur de cette image ROM +(yourrom.rom), et ensuite vous pouvez la reflasher. + This will change the default inside that ROM image, and then you can re-flash it. -Do I need to install a bootloader when installing a distribution? +Ai-je besoin d'installer un chargeur d'amorçage quand j'installe une distribution? --------------------------------------------------------------------------------------------------- -Libreboot integrates the GRUB bootloader already, as a -*[payload](http://www.coreboot.org/Payloads)*. This means that the GRUB -bootloader is actually *flashed*, as part of the boot firmware -(libreboot). This means that you do not have to install a boot loader on -the HDD or SSD, when installing a new distribution. You'll be able to -boot just fine, using the bootloader (GRUB) that is in the flash chip. - -This also means that even if you remove the HDD or SSD, you'll still -have a functioning bootloader installed which could be used to boot a -live distribution installer from a USB flash drive. See -[How to install GNU+Linux on a libreboot system](../docs/gnulinux/grub_boot_installer.md) - -Do I need to re-flash when I re-install a distribution? +Libreboot intègre déjà le chargeur d'amorçage GRUB, en tant que *[charge +utile](http://www.coreboot.org/Payloads)*. Ça veut dire que le chargeur +d'amorçage GRUB est en fait *flashé* comme une partie du micrologiciel de +démarrage (libreboot). Ça signifie que vous n'avez pas besoin d'installer un +chargeur d'amorçage sur le DD/SSD quand vous installez une nouvelle +distribution. Vous serez capable de démarrer juste comme il faut, en utilisant +le chargeur d'amorçage (GRUB) qui est à l'intérieur de la puce flash. + +Ça veut aussi dire que même si vous enlevez le DD ou SSD, vous aurez encore un +chargeur d'amorçage fonctionnel installé qui pourrait être utilisé pour +démarrer un distribution *live* d'une clé USB flash. +Voyez [Comment installer GNU+Linux sur un système +libreboot](../docs/gnulinux/grub_boot_installer.md). + +Ai-je besoin de re-flasher quand je ré-installe une distribution? ------------------------------------------------------------------------------------------- -Not anymore. Recent versions of libreboot (using the GRUB payload) will -automatically switch to a GRUB configuration on the HDD or SSD, if it -exists. You can also load a different GRUB configuration, from any kind -of device that is supported in GRUB (such as a USB flash drive). For -more information, see -[Modifying the GRUB Configuration in Libreboot Systems](../docs/gnulinux/grub_cbfs.md) +Plus maintenant. Les versions récentes de Libreboot (utilisant la charge utile +GRUB) basculeront automatiquement sur une configuration GRUB stocké sur le +DD ou SSD, si elle existe. Vous pouvez aussi chargeur une configuration GRUB +différente, pour n'importe quel type d'appareil qui est supporté dans GRUB +(tel qu'une clef USB flash). Pour plus d'informations, voyez [Modifier la +configuration GRUB dans les systèmes Libreboot](../docs/gnulinux/grub_cbfs.md) -What does a flash chip look like? +À quoi ressemble une puce flash? ----------------------------------------------------------------- -SOIC-8 SPI flash chip: +Puce flash SPI SOIC-8:  -SOIC-16 SPI flash chip: +Puce flash SPI SOIC-16:  -Who did the logo? +Qui a fait le logo? ---------------------------------------------------------------- -See the [license information](logo/license.md). +Voyez [l'information de licence](logo/license.md). -The Libreboot logo is available as a [bitmap](logo/logo.png), a -[vector](logo/logo.svg), or a [greyscale vector](logo/logo_grey.svg). +Le logo de libreboot est disponible en tant que [bitmap](logo/logo.png), un +[vector](logo/logo.svg), ou un [vector avec niveaux de +gris](logo/logo_grey.svg). -Libreboot Inside stickers are available as a -[PDF](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.pdf) or -a -[vector](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.svg) +Les stickers 'Libreboot Inside' sont disponibles en tant que +[PDF](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.pdf) +ou un +[vecteur](logo/stickers/libreboot-inside-simple-bold-1.60cmx2.00cm-diecut-3.svg) -What other firmware exists outside of libreboot? +Quels autres micrologiciels existent en dehors de libreboot? ================================================== -The main freedom issue on any system, is the boot firmware (usually -referred to as a BIOS or UEFI). Libreboot replaces the boot firmware -with fully free code, but even with libreboot, there may still be other -hardware components in the system (e.g. laptop) that run their own -dedicated firmware, sometimes proprietary. These are on secondary -processors, where the firmware is usually read-only, written for very -specific tasks. While these are unrelated to libreboot, technically -speaking, it makes sense to document some of the issues here. - -Note that these issues are not unique to libreboot systems. They apply -universally, to most systems. The issues described below are the most -common (or otherwise critical). - -Dealing with these problems will most likely be handled by a separate -project. - -### External GPUs - -The Video BIOS is present on most video cards. For integrated graphics, -the VBIOS (special kind of OptionROM) is usually embedded -in the main boot firmware. For external graphics, the VBIOS is -usually on the graphics card itself. This is usually proprietary; the -only difference is that SeaBIOS can execute it (alternatively, you embed it -in a coreboot ROM image and have coreboot executes it, if you use a -different payload, such as GRUB). - -On current libreboot systems, instead of VBIOS, coreboot native GPU init is used, -which is currently only implemented for Intel GPUs. -Other cards with proper KMS drivers can be initialized once Linux boots, -but copy of VBIOS may be still needed to fetch proper VRAM frequency -and other similar parameters (without executing VBIOS code). - -In configurations where SeaBIOS and native GPU init are used together, -a special shim VBIOS is added that uses coreboot linear framebuffer. - - -### EC (embedded controller) firmware - -Most (all?) laptops have this. The EC (embedded controller) is a small, -separate processor that basically processes inputs/outputs that are -specific to laptops. For example: - -- When you flick the radio on/off switch, the EC will enable/disable - the wireless devices (wifi, bluetooth, etc) and enable/disable an - LED that indicates whether it's turned on or not -- Listen to another chip that produces temperature readings, adjusting - fan speeds accordingly (or turning the fan(s) on/off). -- Takes certain inputs from the keyboard, e.g. brightness up/down, - volume up/down. -- Detect when the lid is closed or opened, and send a signal - indicating this. +Le problème principal sur n'importe quel système est le micrologiciel de +démarrage (habituellement appelé BIOS ou UEFI). Libreboot remplace le +micrologiciel de démarrage avec du code totalement libre, mais même avec +libreboot, il pourrait y avait d'autres composants matériels dans le système +(p.ex ordinateur portable) qui exécutent leur propre micrologiciel dédicacé, +quelquefois propriétaire. Ceux-ci sont sur des processeurs secondaires, où le +micrologiciel est généralement en lecture seule, écrit pour des tâches très +spécifiques. Bien qu'ils sont sans relation avec libreboot techniquement +parlant, il fait sens de documenter quelques un des problèmes ici. + +Notez que ces problèmes ne sont pas unique à des systèmes libreboot. Ils +s'appliquent universellement, à la majorité des systèmes. Les problèmes décrit +ci-dessousa sont les plus communs (ou autrement critique). + +Faire face à ces problèmes sera certainement géré par un projet séparé. + +### Cartes graphiques externes + +Le BIOS Vidéo est présent sur la majorité des cartes vidéos. Pour les +graphiques intégrés, le VBIOS (type spécial d'OptionROM) sont habituellement +embarqué dans le micrologiciel principal de démarrage. Pour les graphiques +externes, le VBIOS est habituellement sur la carte graphique elle-même. Il (le +VBIOS) typiquement propriétaire; la seule différence est que SeaBIOS peut +l'exécuter, alternativement, vous l'embarquez dans une image ROM de coreboot +et coreboot va l'exécuter, si vous utiilisez une charge utile différente, tel +que GRUB). + +Sur les systèmes libreboot d'en ce moment, au lieu de VBIOS, l'initialisation +native de la carte graphique par coreboot est utilisée, celle-ci étant +implémentée seulement pour les cartes graphiques Intel en ce moment. +Les autres cartes avec de bons pilotes KMS peuvent être initialisés une fois +que Linux démarre, mais une copie du VBIOS serait peut-être encore nécessaire +pour récupérer la bonne fréquence de la VRAM et autre paramètres similares +(sans exécuter le code du VBIOS). + +Dans des configurations ou le SeaBIOS et l'initialisation native de la carte +graphique sont utilisés ensemble, une cale ('shim') spéciale du VBIOS qui utilise le +tampon d'image linéaire de coreboot. + +### Micrologiciel de l'EC (Embedded Controller = contrôleur embarqué) + +La majorité (tous?) des ordinateurs portables ont ceci. L'EC est un petit +processeur séparé qui, basiquement, traite les entrées/sorties qui sont +spécifiques aux ordinateurs portables. Par exemple: + +- Quand vous basculer l'interrupteur radio marche/arrêt, l'EC + activera/désactivera les appareils sans fil (wifi, bluetooth, etc) et + activera/désactivera une LED qui indique si c'est en marche ou non. +- Écoute une autre puce qui produit des lectures de température, ajustant la + vitesse des ventilateurs en accordance (ou met en marche/arrête les + ventilateurs). +- Gère certaines entrées du clavier, p.ex plus/moins de luminosité, + plus/moins de volume. +- Détecte quand l'écran est rabattu ou ouvert, et envoie un signal + l'indiquant. - Etc. -Alexander Couzens from coreboot (lynxis on coreboot IRC) is working on a -free EC firmware replacement for the ThinkPads that are supported in -libreboot. See: <https://github.com/lynxis/h8s-ec> (not ready yet). - -Most (all?) chromebooks have free EC firmware. Libreboot is currently -looking into supporting a few ARM-based chromebooks. - -EC is present on nearly all laptops. Other devices use, depending on complexity, -either EC or variant with firmware in Mask ROM - SuperIO. - -### HDD/SSD firmware - -HDDs and SSDs have firmware in them, intended to handle the internal -workings of the device while exposing a simple, standard interface (such -as AHCI/SATA) that the OS software can use, generically. This firmware -is transparent to the user of the drive. - -HDDs and SSDs are quite complex, and these days contain quite complex -hardware which is even capable of running an entire operating system (by -this, we mean that the drive itself is capable of running its own -embedded OS), even GNU+Linux or BusyBox/Linux. - -SSDs and HDDs are a special case, since they are persistent storage -devices as well as computers. - -Example attack that malicious firmware could do: substitute your SSH -keys, allowing unauthorized remote access by an unknown adversary. Or -maybe substitute your GPG keys. SATA drives can also have DMA (through -the controller), which means that they could read from system memory; -the drive can have its own hidden storage, theoretically, where it could -read your LUKS keys and store them unencrypted for future retrieval by -an adversary. - -With proper IOMMU and use of USB instead of SATA, it might be possible -to mitigate any DMA-related issues that could arise. - -Some proof of concepts have been demonstrated. For HDDs: -<https://spritesmods.com/?art=hddhack&page=1> For SSDs: +Alexander Couzens de coreboot (lynxis sur l'IRC de coreboot) est en train de +travailler sur un remplacement libre du micrologiciel de l'EC pour les +ThinkPads étants supportés par Libreboot. Voyez +<https://github.com/lynxis/h8s-ec> (pas encore prêt). + +La majorité (tous?) les chromebooks ont un micrologiciel d'EC libre. Libreboot +est en ce moment en train de considérer le support de quelques chromebooks +basés sur l'architecture ARM. + +L'EC est présent sur presque tout ordinateur portable. Les autres appareils +utilisent, dépendant de leur complexité, soit l'EC ou une variante avec le +micrologiciel dans la 'Mask ROM' - SuperIO. + +### Micrologiciel du DD/SSD + +Les DDs et SSDs ont un micrologiciel eux, sensé gérer les fonctionnements +internes de l'appareil tout en exposant un interface standard et simple (tel +que AHCI/SATA) que le logiciel du système d'exploitationpeut utiliser, +génériquement. Ce micrologiciel est opaque pour l'utilisateur du disque. + +Les DD et SSDs sont plutôt complexes, et de nos jours contiennent du matériel +plutôt complexe qui est même capable d'exécuter un système d'exploitation tout +entier (par celà , on veut dire que le disque en lui-même est capable de faire +marcher son propre système d'exploitation embarqué), même GNU+Linux ou +BusyBox/Linux. + +Les DDs et SSDs sont un cas spécial, puisqu'ils sont des appareils de +stockage persistants ainsi que des ordinateurs. + +Exemple d'attaque qu'un micrologiciel malveillant pourrait faire: soudoyer +vos clés SSH, autorisant un accés à distance par un adversaire inconnu. Ou +peut-être voler vos clés GPG. Les disques SATA ont aussi le DMA (à travers le +controleur), voulant dire qu'ils pourraient lire la mémoire du système; le +disque peut avoir son propre stockage caché, théoriquement, où il pourrait +lire votre clé LUKS et les stocker non chiffrée pour une future récupération +par un adversaire. + +Avec un bon IOMMU et utilisation de l'USB au lieu de SATA, il pourrait être +possible de mitiger tout problèmes concernant le DMA (direct memory access) +qui pourrait se présenter. + +Quelques preuves conceptuelles ont été démontrée. Pour les DDs +<https://spritesmods.com/?art=hddhack&page=1>. +Pour les SSDs: <http://www.bunniestudios.com/blog/?p=3554> -Viable free replacement firmware is currently unknown to exist. For -SSDs, the -[OpenSSD](http://www.openssd-project.org/wiki/The_OpenSSD_Project) -project may be interesting. +L'existence d'un remplacement libre du micrologicel viable n'est pour +l'instant pas connue. Pour les SSDs, le projet +[OpenSSD](http://www.openssd-project.org/wiki/The_OpenSSD_Project) pourrait +être intéressant. -Apparently, SATA drives themselves don't have DMA but can make use of -it through the controller. This +Apparemment, les disques SATA eux-mêmes n'ont pas le DMA mais peuvent le +manipuler à travers le contrôleur. +Regardez <http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf> -(pages 388-414, 420-421, 427, 446-465, 492-522, 631-638) and this +(pages 388-414, 420-421, 427, 446-465, 492-522, 631-638) et ça <http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf> (pages 59, 67, 94, 99). -The following is based on discussion with Peter Stuge (CareBear\\) in -the coreboot IRC channel on Friday, 18 September 2015, when -investigating whether the SATA drive itself can make use of DMA. The -following is based on the datasheets linked above: - -According to those linked documents, FIS type 39h is *"DMA Activate FIS -- Device to Host"*. It mentions *"transfer of data from the host to -the device, and goes on to say: Upon receiving a DMA Activate, if the -host adapter's DMA controller has been programmed and armed, the host -adapter shall initiate the transmission of a Data FIS and shall transmit -in this FIS the data corresponding to the host memory regions indicated -by the DMA controller's context."* FIS is a protocol unit (Frame -Information Structure). Based on this, it seems that a drive can tell -the host controller that it would like for DMA to happen, but unless the -host software has already or will in the future set up this DMA transfer -then nothing happens. **A drive can also send DMA Setup**. If a DMA -Setup FIS is sent first, with the Auto-Activate bit set, then it is -already set up, and the drive can initiate DMA. The document goes on to -say *"Upon receiving a DMA Setup, the receiver of the FIS shall -validate the received DMA Setup request."* - in other words, the host -is supposed to validate; but maybe there's a bug there. The document -goes on to say *"The specific implementation of the buffer identifier -and buffer/address validation is not specified"* - so noone will -actually bother. *"the receiver of the FIS"* - in the case we're -considering, that's the host controller hardware in the chipset and/or -the kernel driver (most likely the kernel driver). All SATA devices have -flash-upgradeable firmware, which can usually be updated by running -software in your operating system; **malicious software running as root -could update this firmware, or the firmware could already be -malicious**. Your HDD or SSD is the perfect place for a malicious -adversary to install malware, because it's a persistent storage device -as well as a computer. - -Based on this, it's safe to say that use of USB instead of SATA is -advisable if security is a concern. USB 2.0 has plenty of bandwidth for -many HDDs (a few high-end ones can use more bandwidth than USB 2.0 is -capable of), but for SSDs it might be problematic (unless you're using -USB 3.0, which is not yet usable in freedom. See - -Use of USB is also not an absolute guarantee of safety, so do beware. -The attack surface becomes much smaller, but a malicious drive could -still attempt a "fuzzing" attack (e.g. sending malformed USB -descriptors, which is how the tyrant DRM on the Playstation 3 was -broken, so that users could run their own operating system and run -unsigned code). (you're probably safe, unless there's a security flaw -in the USB library/driver that your OS uses. USB is generally considered -one of the safest protocols, precisely because USB devices have no DMA) - -Other links: - +Ce qui suit est basé sur des discussions avec Peter Stuge (Carebear\\) dans le +canal IRC de coreboot le Vendredi 18 Septembre 2015, lors de l'investigation +si oui ou non le disque SATA en lui même peut utiliser le DMA. +Le suivant est basé sur les fiches techniques mises en lien juste au dessus: + +D'après ces documents mis en lien, le FIS type 39h est *"DMA Activate FIS - +appareil vers hôte"*. Ça mentionne le *"transfert de données de l'hôte vers +l'appareil, et continue pour déclarer: lors de la réception d'un DMA Activate, +si l'adapteur du contrôleur DMA de l'hôte a été programmé et armé, l'adapteur +hôte doit initier la transmission d'un Data FIS et doit transmettre dans ce +FIS les données correspondantes aux régions de la mémoire hôte indiquées par +le contexte du contrôleur DMA."* +FIS est une unité de protocole (Frame Information Structure = Information +de Structure de Trames). Basé sur cela, il semble qu'un disque peut dire le +contrôleur hôte qu'il voudrait que le DMA se fasse, mais à moins que le +logiciel hôte a déjà configuré ou configurera le transfer DMA, alors rien ne se +passe.**Un disque peut aussi envoyer des configurations/mises en place DMA**. +Si un FIS de configuration DMA est d'abord envoyé, avec le bit Auto-Activate +défini, alors c'est qu'il est déjà configuré, et le disque peut initier le +DMA. Le document enchaîne pour dire *"lors de la réception d'une configuration +DMA, le récepteur de la FIS doit valider la requête de configuration DMA +reçue."* - en d'autres mots, l'hôté est supposé valider; mais peut-être il y a +un bug là -bas. Le document continue, *"L'implémentation spécifique +de l'identifieur de tampon et de la validation du tampon/adresse n'est pas +spécifiée"* - donc personne ne va véritablement y faire attention. *"Le +récepteur de la FIS"* - dans le cas que nous considérons, c'est le matériel du +contrôleur hôte dans le jeu de puces et/ou le pilote du kernel (plus +probablement le pilote du kernel). Tout les périphériques SATA ont un +micrologiciel pouvant être mis à jour via flashage, qui peut être +habituellement mis à jour en exécutant un logiciel dans votre système +d'exploitation; **un maliciel s'exécutant avec des droits root pourrait mettre +à jour ce micrologiciel, ou le micrologiciel pourrait être déjà malicieux**. +Votre DD/SSD est le lieu parfait pour un adversaire malveillant, parce que +c'est un périphérique de stockage persistent ainsi qu'un ordinateur. + +En se basant sur ça, on peut dire sans crainte que l'utilisation de l'USB au +le de SATA est à conseiller si la sécurité est une préoccupation. L'USB 2.0 a +plein de bande passante pour pas mal de DDs (quelques uns haut de gamme +peuvent utiliser plus de bande passante qu'USB 2.0 n'en est capable), mais +pour les SSDs ça pourrait être problématique (à moins que vous utilisiez USB +3.0, qui n'est pas encore utilisable en liberté. + +L'utilisation de l'USB n'est aussi pas une garantie absolue de sécurité, donc +faites attention. +La surface d'attaque devient bien plus pette, mais un disque malveillant +pourrait encore tenter une attaque "fuzzing" (injection de données +aléatoires +pour tester un logiciel, p.ex ici, envoyer des descripteurs USB +malformés, qui +est d'ailleus comment la DRM tyrannique de la PlayStation 3 a été +cassée, permettant aux utilisateurs d'exécuter leur propre système +d'exploitation et exécuter du code non signé). +(Vous être probablement en sécurité, à moins qu'il y a une faille de sécurité +dans la bibliothèque/pilote que votre système d'exploitation utilise. L'USB +est généralement considéré comme l'un des protocoles les plus sécurisés, +précisément parce que les périphériques USB n'ont pas le DMA). + +Autres liens: - <http://motherboard.vice.com/read/the-nsas-undetectable-hard-drive-hack-was-first-demonstrated-a-year-ago> -It is recommended that you use full disk encryption, on HDDs connected -via USB. There are several adapters available online, that allow you to -connect SATA HDDs via USB. Libreboot documents how to install several -distributions with full disk encryption. You can adapt these for use -with USB drives: +Il est recommandé que vous utilisez le chiffrement du disque tout entier sur +les DDs connectés via USB. Il y a pas mal d'adaptateurs en ligne disponibles, +permettant de connecter un DD SATA via USB. Libreboot documente comment +installer quelques distributions avec le chiffrement du disque tout entier. +Vous pouvez adapter ceux-là pour une utilisation avec des clés USB: -- [Full disk encryption with Debian](../docs/gnulinux/encrypted_debian.md) -- [Full disk encryption with Parabola](../docs/gnulinux/encrypted_parabola.md) +- [Chiffrement du disque tout entier avec Debian](../docs/gnulinux/encrypted_debian.md) +- [Chiffrement du disque tout entier avec Parabola](../docs/gnulinux/encrypted_parabola.md) -The current theory (unproven) is that this will at least prevent -malicious drives from wrongly manipulating data being read from or -written to the drive, since it can't access your LUKS key if it's only -ever in RAM, provided that the HDD doesn't have DMA (USB devices don't -have DMA). The worst that it could do in this case is destroy your data. -Of course, you should make sure never to put any keyfiles in the LUKS -header. **Take what this paragraph says with a pinch of salt. This is -still under discussion, and none of this is proven.** +La théorie (non prouvée) en ce moment est que ça empêchera au moins des +disques malveillants de manipuler de manière erronée des données étant lues ou +écrites du disque, puisque il ne peut pas accéder votre clé LUKS si elle est +jamais dans la RAM, en admettant que le DD n'a pas le DMA (les périphériques +USB ne l'ont pas). Le pire qu'il pourrait faire dans ce cas est détruire vos +données. Bien sûr, vous devriez vous assurer que vous ne mettez jamais de +fichiers clés dans l'en-tête LUKS. **Prenez ce paragraphe avec une pincée de +sel. C'est encore en discussion, et rien de celà n'a été prouvé**. -### NIC (ethernet controller) +### NIC (contrôleur Ethernet) -Ethernet NICs will typically run firmware inside, which is responsible -for initializing the device internally. Theoretically, it could be -configured to drop packets, or even modify them. +Les cartes réseaux Ethernet exécuteront typiquement un micrologiciel à +l'intérieur d'elles, qui est responsable à l'initialisation interne de +l'appareil. Théoriquement, il pourrait être configuré pour ignorer des +paquets, ou même les modifier. -With proper IOMMU, it might be possible to mitigate the DMA-related -issues. A USB NIC can also be used, which does not have DMA. +Avec un bon IOMMU, il pourrait être possible de mitiger les problèmes +concernant la DMA. Un carte réseau USB (qui n'a pas le DMA) pourrait être aussi utilisée. -### CPU microcode +### microde du processeur Implements an instruction set. See description. Here we mean microcode built in to the CPU. We are not @@ -1140,7 +1194,7 @@ Unknown. Probably not. Where can I learn more about electronics ========================================== - +: * Basics of soldering and rework by PACE Both series of videos are mandatory regardless of your soldering skill. * [Basic Soldering](https://www.youtube.com/watch?v=vIT4ra6Mo0s&list=PL926EC0F1F93C1837) |