On ne peut pas tout remplacer du ME, à moins d'être fondeur, et du moins pour le moment, car le service se découpe en deux parties distinctes : celle dans la puce spi (puce contenant le chargeur, ses payloads comme une interface bios et une init vga, et le ME [et à côté un grub et/ou directement un noyau s'il reste de la place]) et une partie encore plus obscure que le me spi dans une puce d'architecture arc (argonaut risc proco) contenant une clef privé pour le me. Cette dernière partie n'est pas atteignable pour ré-écriture par des moyens habituels. Par analogie on entends donc souvent "me = code me dans le spi", car c'est la partie essentielle, celle dans laquelle on trouve toutes les goodies (accès dma / oob, réseau, etc ..)
Ensuite ce service se découpe en 2 options : une version 2Mo, une ~6Mo. Ces 2 types/options offrent différent niveaux de possibilités, allant de "pas grand chose" jusqu'à "contrôle total distant", en passant par un "lms" (local management service). Les laptops (et les ordis de bureau), tous, ont à minima la version 2Mo. Certains laptops de classe entreprise ont la version ~6Mo, et les serveurs aussi. Désolé de ne pas être plus précis, je ne maitrise pas le sujet, vejmarie corrigera peut être si grosse bourde.
Un peu de lecture (plus récente que des trucs de 2014 :p) https://mail.coreboot.org/pipermail/coreboot/2016-November/082333.html https://mail.coreboot.org/pipermail/coreboot/2016-November/082335.html https://github.com/skochinsky/me-tools https://github.com/corna/me_cleaner https://review.coreboot.org/#/c/19849/ (ce lien juste pour signaler les très belles avancées du projet purism)
& le + vieux : https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt On appréciera particulièrement la possibilité d'un accès total et complet même en état s2 (veille d'un laptop par exemple)
Les deux parties essentielles sont : désactiver toute la stack réseau du me, et désactiver l'accès au me par le noyau.
Pour un laptop de classe 'parano', désactiver en plus tout ce qui permet d'avoir un accès usb/fw/esata/hdmi -> me.
Les pb rencontrés actuellement sur les laptops semblent variés après un me_cleaner : pb de stabilité et de performances sont rapportés. (Sur des acer c7x, aucun pb.)
À noter que chez amd c'est encore pire, puisque plutôt que d'avoir un proco arc dans un bridge, ils ont carrément foutu un proco arm lambda dans le cpu, dans leur dernière génération, qui semble t il fourni le même type de services (clef privée dans le proco arm, avec lequel l'équivalent du me dans le spi discute au pré-boot)
Il n'est pas illusoire d'avoir un serveur totalement libre :-)
[^] # Re: Chtite question
Posté par bubar🦥 . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 10. Dernière modification le 01 juillet 2017 à 09:14.
On ne peut pas tout remplacer du ME, à moins d'être fondeur, et du moins pour le moment, car le service se découpe en deux parties distinctes : celle dans la puce spi (puce contenant le chargeur, ses payloads comme une interface bios et une init vga, et le ME [et à côté un grub et/ou directement un noyau s'il reste de la place]) et une partie encore plus obscure que le me spi dans une puce d'architecture arc (argonaut risc proco) contenant une clef privé pour le me. Cette dernière partie n'est pas atteignable pour ré-écriture par des moyens habituels. Par analogie on entends donc souvent "me = code me dans le spi", car c'est la partie essentielle, celle dans laquelle on trouve toutes les goodies (accès dma / oob, réseau, etc ..)
Ensuite ce service se découpe en 2 options : une version 2Mo, une ~6Mo. Ces 2 types/options offrent différent niveaux de possibilités, allant de "pas grand chose" jusqu'à "contrôle total distant", en passant par un "lms" (local management service). Les laptops (et les ordis de bureau), tous, ont à minima la version 2Mo. Certains laptops de classe entreprise ont la version ~6Mo, et les serveurs aussi. Désolé de ne pas être plus précis, je ne maitrise pas le sujet, vejmarie corrigera peut être si grosse bourde.
Un peu de lecture (plus récente que des trucs de 2014 :p)
https://mail.coreboot.org/pipermail/coreboot/2016-November/082333.html
https://mail.coreboot.org/pipermail/coreboot/2016-November/082335.html
https://github.com/skochinsky/me-tools
https://github.com/corna/me_cleaner
https://review.coreboot.org/#/c/19849/ (ce lien juste pour signaler les très belles avancées du projet purism)
& le + vieux :
https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt
On appréciera particulièrement la possibilité d'un accès total et complet même en état s2 (veille d'un laptop par exemple)
Les deux parties essentielles sont : désactiver toute la stack réseau du me, et désactiver l'accès au me par le noyau.
Pour un laptop de classe 'parano', désactiver en plus tout ce qui permet d'avoir un accès usb/fw/esata/hdmi -> me.
Les pb rencontrés actuellement sur les laptops semblent variés après un me_cleaner : pb de stabilité et de performances sont rapportés. (Sur des acer c7x, aucun pb.)
À noter que chez amd c'est encore pire, puisque plutôt que d'avoir un proco arc dans un bridge, ils ont carrément foutu un proco arm lambda dans le cpu, dans leur dernière génération, qui semble t il fourni le même type de services (clef privée dans le proco arm, avec lequel l'équivalent du me dans le spi discute au pré-boot)
Il n'est pas illusoire d'avoir un serveur totalement libre :-)