Use of a Linux initramfs to fully automate the bootstrapping process
504
stars
36
forks
source link
Kernel deblob script removes entire drivers for having even optional external firmware file loading support, including r8169 (most common Gigabit Ethernet chipsets) #330
Testing bare-metal bootstrapping on an Asus P5K Premium revealed that the r8169 Ethernet driver is being removed in its entirety by deblob. This driver contains no embedded blobs, only uses external firmware files optionally (works without them, just e.g. uses more power), and it's a requirement for Ethernet on the majority of consumer motherboards and NICs that would be used for bare-metal. (Luckily this board also has a Marvell Yukon Ethernet chip, which is unaffected.)
This was discovered during the workup of #329 (all Ethernet drivers disabled in config, except the ones used by qemu).
While deblobbing, in the sense of removing blobs embedded in kernel driver code, is certainly a necessity to ensure the trustworthiness of the bootstrap environment, removing the firmware loading mechanism, and especially entire drivers that depend on or even just optionally use it, seems way too excessive - firmware loading alone can't compromise the environment, provided that the corresponding firmware files aren't present (which is already the case, since we don't include linux-firmware).
Testing bare-metal bootstrapping on an Asus P5K Premium revealed that the r8169 Ethernet driver is being removed in its entirety by deblob. This driver contains no embedded blobs, only uses external firmware files optionally (works without them, just e.g. uses more power), and it's a requirement for Ethernet on the majority of consumer motherboards and NICs that would be used for bare-metal. (Luckily this board also has a Marvell Yukon Ethernet chip, which is unaffected.)
This was discovered during the workup of #329 (all Ethernet drivers disabled in config, except the ones used by qemu).
While deblobbing, in the sense of removing blobs embedded in kernel driver code, is certainly a necessity to ensure the trustworthiness of the bootstrap environment, removing the firmware loading mechanism, and especially entire drivers that depend on or even just optionally use it, seems way too excessive - firmware loading alone can't compromise the environment, provided that the corresponding firmware files aren't present (which is already the case, since we don't include linux-firmware).