[flashrom] Porting flashrom to OpenBSD

[Carl-Daniel Hailfinger]

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