- Il ne s'agit pas de code noyau ni même de code userland : ça tourne sur du matériel séparé (par ex. sur le proc de la carte réseau ou scsi).
- Pour la sécurité : le firmware tourne dans le matériel, la compromission possible de l'OS dépend seulement de ce qu'on accepte venant du matériel . Qu'il soit distribué avec l'OS ou pas ne change absolument rien. Et une même bombe logique pourrait être intégrée directement dans le design électronique du chipset (donc la question n'est même pas spécifique au monde du logiciel).
- OpenBSD a déjà choisi d'accepter les firmwares binaires dans base*.tgz (à condition qu'ils soient librement redistribuables)
- Tu mélange firmwares binaires (acceptés jusqu'à présent dans OpenBSD et Debian Sarge - et en fait, toutes les distros que je connaît) et drivers non libres (refusés par ces deux, et où OpenBSD se distingue par son militantisme sans concession).
- Ce que les devs. d'OpenBSD appellent « blob » ce sont des objets binaires chargés dans l'espace noyau par un pseudo driver minimaliste (un wrapper autour de l'objet binaire propriétaire). Rien à voir avec les firmwares.
- Le cas des chipsets wireless d'Intel est spécifique en ceci qu'ils ont d'abord fait des histoires au sujet de la redistribution de leur firmware (qu'ils n'autorisaient que sous condition) et ensuite par l'affaire du chipset 3945 (le driver Linux de ce chipset, écrit par Intel, est libre mais nécessite un daemon userland binaire proprio, cf. http://kerneltrap.org/node/6650 ).
[^] # Re: Une 4ème option ?
Posté par herodiade . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 10.
- Il ne s'agit pas de code noyau ni même de code userland : ça tourne sur du matériel séparé (par ex. sur le proc de la carte réseau ou scsi).
- Pour la sécurité : le firmware tourne dans le matériel, la compromission possible de l'OS dépend seulement de ce qu'on accepte venant du matériel . Qu'il soit distribué avec l'OS ou pas ne change absolument rien. Et une même bombe logique pourrait être intégrée directement dans le design électronique du chipset (donc la question n'est même pas spécifique au monde du logiciel).
- OpenBSD a déjà choisi d'accepter les firmwares binaires dans base*.tgz (à condition qu'ils soient librement redistribuables)
- Tu mélange firmwares binaires (acceptés jusqu'à présent dans OpenBSD et Debian Sarge - et en fait, toutes les distros que je connaît) et drivers non libres (refusés par ces deux, et où OpenBSD se distingue par son militantisme sans concession).
- Ce que les devs. d'OpenBSD appellent « blob » ce sont des objets binaires chargés dans l'espace noyau par un pseudo driver minimaliste (un wrapper autour de l'objet binaire propriétaire). Rien à voir avec les firmwares.
- Le cas des chipsets wireless d'Intel est spécifique en ceci qu'ils ont d'abord fait des histoires au sujet de la redistribution de leur firmware (qu'ils n'autorisaient que sous condition) et ensuite par l'affaire du chipset 3945 (le driver Linux de ce chipset, écrit par Intel, est libre mais nécessite un daemon userland binaire proprio, cf. http://kerneltrap.org/node/6650 ).