On 25.06.2010 17:20, Theo de Raadt wrote:
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs.
PCI config space writes (usually only to the PCI<->LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years.
flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip).
I understand very well what you are trying to do.
But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode.
Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a "hole" for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working.
What's the correct way forward for flashrom on OpenBSD?
Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix.
The Unix interfaces for hardware access usually have a reasonable level of abstraction as well, and flashrom makes use of that to run on pretty much any OS.
flashrom is essentially a self-contained driver+frontend in userspace and thus very similar to X. It would be possible to move all hardware access into a kernel driver, but such a kernel driver would (if you really care about userspace not being able to screw up) have in excess of 25000 lines of code, constantly growing. That's the point where kernel maintainers usually run away screaming.
The minimalistic and still somewhat safe approach is to have flashrom generate a list of PCI config space locations it needs to read/write, and whitelist only those in a kernel driver. Such a whitelist would reduce the amount of damage another userspace app with the same privileges could cause, and it's way better than a blacklist which will never be exhaustive. That kernel driver would also allow opening /dev/flashrom_memory which is essentially /dev/mem restricted to the regions which are absolutely necessary.
Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD.
I don't buy any of that stuff. By the time this has happened, you're already hosed.
Not necessarily. You can easily boot with a known-clean flash chip, then (once the machine is booted) hot-swap the flash chip and read out the new flash chip. No code from the new flash chip will be executed. In fact, you can remove the flash chip after booting and run the machine without a flash chip forever (until you need to boot again). As long as the flash chip technology is compatible, you can exchange them regardless of mainboard chipset or CPU. This only applies to i386/amd64, I have no idea about other architectures.
Regards, Carl-Daniel