Les processeurs de service ayant la main en premier en sortie de reset se généralisent.
Certes, sur ARM c'est en général basé sur une implémentation de référence open source mais rien n'assure que les patch d'un fondeur de SoC soient présents vu la licence BSD: De fait, les sources d'un SCP ou autre ATF fournies par un fondeur diffèrent de celles du github de ARM (https://github.com/ARM-software) par exemple, seules les évolutions non spécifiques semblant assez systématiquement remontées. Chacun peut donc ici conserver ses petites subtilités, ceux qui développent des produits basés sur un SoC précis ont accès aux sources et n'ont pas à jouer aux devinettes sur les problèmes voir peuvent remonter les patch au fondeur sur des pb qu'il ne peut pas forcément reproduire: Tout les acteurs industriels sont contents, sauf en fait le client final qui achète le matos s'il est bidouilleur.
Se passer de ces firmwares, quand c'est possible, doit par ailleurs avoir certains impacts niveau design (afin de ne pas devoir compter sur les protections thermiques et autres): Un ME chez Intel ne sera par exemple à ma connaissance jamais totalement inactif mais dans un mode dégradé (recovery): Il y en a de toutes manières un morceau gravé en dur (non upgradable) dans le PCH, en plus de ce qui est dans la boot flash (dans une section upgradable, avec ou séparément du reste du bios). Pour moi cette partie PCH n'est pas évitable, en premier lieu car c'est elle qui fait la découverte de la boot flash SPI (RSFDP, c'est d'ailleurs une dépendance implicite entre ME et BIOS assez dégueulasse et source de problèmes tordus!): C'est la première commande qu'on voit passer après le reset quand on mets un Salae en espion sur l'interface SPI boot... et un bios ne repasse pas sur les configurations faites à ce moment (adressage 3 ou 4 bytes en particulier) et attends même un certain comportement derrière en fonction du type/taille de flash (>16Mbyte ou pas, en particulier). D’où des plantages possibles dès que le driver SPI du bios va prendre la main, assez tôt dans l’exécution du BIOS (pour écrire/lire de l'environnement par exemple, le MRC Intel y mets plein de valeurs de calibration DDR par exemple => Si l'adressage utilisé par le bios ne match pas avec ce que le ME est censé avoir initialisé, on ne passe même pas l'init DDR!).
[^] # Re: Matériel backdoor inside et vidéo disponible ?
Posté par lym . En réponse à la dépêche Conférence « Les libertés du logiciel et du matériel » avec Richard Stallman. Évalué à 1.
Les processeurs de service ayant la main en premier en sortie de reset se généralisent.
Certes, sur ARM c'est en général basé sur une implémentation de référence open source mais rien n'assure que les patch d'un fondeur de SoC soient présents vu la licence BSD: De fait, les sources d'un SCP ou autre ATF fournies par un fondeur diffèrent de celles du github de ARM (https://github.com/ARM-software) par exemple, seules les évolutions non spécifiques semblant assez systématiquement remontées. Chacun peut donc ici conserver ses petites subtilités, ceux qui développent des produits basés sur un SoC précis ont accès aux sources et n'ont pas à jouer aux devinettes sur les problèmes voir peuvent remonter les patch au fondeur sur des pb qu'il ne peut pas forcément reproduire: Tout les acteurs industriels sont contents, sauf en fait le client final qui achète le matos s'il est bidouilleur.
Se passer de ces firmwares, quand c'est possible, doit par ailleurs avoir certains impacts niveau design (afin de ne pas devoir compter sur les protections thermiques et autres): Un ME chez Intel ne sera par exemple à ma connaissance jamais totalement inactif mais dans un mode dégradé (recovery): Il y en a de toutes manières un morceau gravé en dur (non upgradable) dans le PCH, en plus de ce qui est dans la boot flash (dans une section upgradable, avec ou séparément du reste du bios). Pour moi cette partie PCH n'est pas évitable, en premier lieu car c'est elle qui fait la découverte de la boot flash SPI (RSFDP, c'est d'ailleurs une dépendance implicite entre ME et BIOS assez dégueulasse et source de problèmes tordus!): C'est la première commande qu'on voit passer après le reset quand on mets un Salae en espion sur l'interface SPI boot... et un bios ne repasse pas sur les configurations faites à ce moment (adressage 3 ou 4 bytes en particulier) et attends même un certain comportement derrière en fonction du type/taille de flash (>16Mbyte ou pas, en particulier). D’où des plantages possibles dès que le driver SPI du bios va prendre la main, assez tôt dans l’exécution du BIOS (pour écrire/lire de l'environnement par exemple, le MRC Intel y mets plein de valeurs de calibration DDR par exemple => Si l'adressage utilisé par le bios ne match pas avec ce que le ME est censé avoir initialisé, on ne passe même pas l'init DDR!).