[now this comment became much too long and rambling... ;-) ]
Regarding erase/write protection of flash-memories:
Besides the actual user-acessible bulk-data, a flash-chip typically has additional configuration data that store write-protection of the whole device or parts of the memory (pages). This protection typically is done so that the device is not accidentally overwritten by a misbehaving program (e.g. a process in kernel-space writing randomly to addresses).
Take for example the Intel 28F128[1] (128Mbit) which will appear as a 16bit wide memory on a processor's address/data bus (or some version interfaced to the processor by the northbridge, the details can be found in the AMI Bios sourcecode :-) ). Normally you only read the addresses the flash is mapped to, and you will get your stored data (called "read matrix" mode).
But to make the flash do something special, like identifying itself, executing erase-commands, protecting or un-protecting sectors, you will write some special word to its "command" address: Subsequently the flash will no longer output the stored user-data on reads to its address, but rather whatever the chosen command defines.
For example to identify the flash according to the CFI specificytion, you write the data-value 0x55h to the flash-address 0x98[2], then you will no longer read out user-data, but information about the flash-chip, the manufacturer, timing, ...
To see how that works, you can have a look at the code in u-boot, a pretty common bootloader for arm-, m68k- or mips(?) devices[3], e.g. write_buff() in line #1313, flash_Erase() in #1049. The feature for "write protecting" pages in the 28F128 is called locking/unlocking the data-sheet. "Protection" in the datasheet refers to a different mechanism.
Also the 28F128 _does_ _indeed_ have a hardware write-protect pin (called #WP), and this might be connected to a jumper, or to a GPIO pin as a added layer of protection. But I haven't seen that being implemented "in the wild", at least in embededd devices.
So the only thing a application needs to flash your BIOS is typically a mapping of the processors address/data-bus to the flash-chip, and access to these addresses, either directly from a driver running in 1:1 mapped kernel address-space or mmap()-ed to user-memory. That's how the typical butt-ugly flash-program running directly under Windows7 does it.
(and yes, I know, some devices nowadays employ a mask-programmed mini-loader that loads the 2nd-stage bootloader e.g. from a serial memory, or a mmc/sdcard, as parallel flash such as the 28F128 is a little outdated already)
My point is that to secure the BIOS you must latch this WP bit after the "press whatever to enter setup" message is gone and you must not accept SWAWARD as wildcard password.
If you fail at these, your system is insecure even in presence of BIOS signing.
If you implement these properly, your system is secure even without BIOS signing.
Ergo, BIOS signing is pointless as a security measure and author's whining about this leak putting users at risk is unjustified.
Well, BIOS flash tools would work in this case by flashing the new BIOS on reboot using a feature of the existing BIOS, which is when the BIOS signature would be validated.
Comments
[now this comment became much too long and rambling... ;-) ]
Regarding erase/write protection of flash-memories:
Besides the actual user-acessible bulk-data, a flash-chip typically has additional configuration data that store write-protection of the whole device or parts of the memory (pages). This protection typically is done so that the device is not accidentally overwritten by a misbehaving program (e.g. a process in kernel-space writing randomly to addresses).
Take for example the Intel 28F128[1] (128Mbit) which will appear as a 16bit wide memory on a processor's address/data bus (or some version interfaced to the processor by the northbridge, the details can be found in the AMI Bios sourcecode :-) ). Normally you only read the addresses the flash is mapped to, and you will get your stored data (called "read matrix" mode).
But to make the flash do something special, like identifying itself, executing erase-commands, protecting or un-protecting sectors, you will write some special word to its "command" address: Subsequently the flash will no longer output the stored user-data on reads to its address, but rather whatever the chosen command defines.
For example to identify the flash according to the CFI specificytion, you write the data-value 0x55h to the flash-address 0x98[2], then you will no longer read out user-data, but information about the flash-chip, the manufacturer, timing, ...
To see how that works, you can have a look at the code in u-boot, a pretty common bootloader for arm-, m68k- or mips(?) devices[3], e.g. write_buff() in line #1313, flash_Erase() in #1049. The feature for "write protecting" pages in the 28F128 is called locking/unlocking the data-sheet. "Protection" in the datasheet refers to a different mechanism.
Also the 28F128 _does_ _indeed_ have a hardware write-protect pin (called #WP), and this might be connected to a jumper, or to a GPIO pin as a added layer of protection. But I haven't seen that being implemented "in the wild", at least in embededd devices.
So the only thing a application needs to flash your BIOS is typically a mapping of the processors address/data-bus to the flash-chip, and access to these addresses, either directly from a driver running in 1:1 mapped kernel address-space or mmap()-ed to user-memory. That's how the typical butt-ugly flash-program running directly under Windows7 does it.
(and yes, I know, some devices nowadays employ a mask-programmed mini-loader that loads the 2nd-stage bootloader e.g. from a serial memory, or a mmc/sdcard, as parallel flash such as the 28F128 is a little outdated already)
[1] http://media.digikey.com/pdf/Data%20Sheets/Intel%20PDFs/28F1...
[2] http://wayback.archive.org/web/20090306191719/http://www.jed...
[3] http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/cfi_fl...
My point is that to secure the BIOS you must latch this WP bit after the "press whatever to enter setup" message is gone and you must not accept SWAWARD as wildcard password.
If you fail at these, your system is insecure even in presence of BIOS signing.
If you implement these properly, your system is secure even without BIOS signing.
Ergo, BIOS signing is pointless as a security measure and author's whining about this leak putting users at risk is unjustified.
Well, BIOS flash tools would work in this case by flashing the new BIOS on reboot using a feature of the existing BIOS, which is when the BIOS signature would be validated.