The other week, at the 3rd RISC-V Workshop, there were 2 firmware presentations, coreboot and UEFI, pitching their solution for the new RISC-V chip.
One point mentioned in the coreboot presentation that seems worth raising here on a firmware security blog: the distinction between firmware that fully exits -vs- firmware that stays resident while the operating system runs. An interesting way to frame it.
Click to access Tues1345%20riscvcoreboot.pdf
Starting with the IBM PC’s BIOS, Intel systems have had firmware that runs in the background. The OS or an ap would issue a BIOS (or DOS) interrupt, and the BIOS responded to low-level interrupts, like Int 13h for disk, 10h for video, etc. On original PCs, IHVs extended BIOS via Option ROMs via the same extensibility method that IBM PC-DOS ‘services’ (TSRs, ‘terminate and stay resident’) used: hook an interrupt and replace it with yours. So, BIOS is kind of a ‘terminate and stay resident’ firmware.
UEFI uses the same model, presuming firmware to be present in background for OS to call, the resident portion are called UEFI RunTime Services. Once the operating system initializes, it calls UEFI’s ExitBootServices() function, which terminate most — but not all — of UEFI, discarding the init code and only keeping the runtime service code.
http://wiki.phoenix.com/wiki/index.php/EFI_BOOT_SERVICES#ExitBootServices.28.29
Coreboot — and U-Boot — initialize the hardware, but do not stay resident. However, on Intel systems, use of a BIOS payload in coreboot, eg, SeaBIOS, will result in that BIOS payload staying resident, responding to BIOS interrupts that the OS (or an app) may call.
So, the resident -vs- nonresident firmware seems to be tied to Intel -vs- non-Intel: coreboot on ARM for example has no SeaBIOS payload, and RISC-V likey won’t use an Intel-centric BIOS payload.
As the coreboot presentation points out, the resident firmware is an additional attack vector, UEFI has a larger surface than coreboot — or U-Boot — due to UEFI Runtime Services. UEFI currently only has the option to terminate Boot Time Services — via ExitBootServices(). I wonder if UEFI could have an additional mode, with an ExitRuntimeServices(), that could make UEFI competitive with coreboot/U-Boot w/r/t attack surface? That could be interesting.
Firmware Security 