-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
When a boot ROM fires (it was via INT19 IIRC), the boot ROM runs, terminates and leaves the system. The size is smaller, it's not persistent, and it can't communicate with anything on the OS.
The UEFI is persistently running at the background, has communication pipes with the OS (some of it is visible via /sys/firmware/efi), and has much larger surface like direct access to disks and network stack via drivers.
There's also at least one open source sound driver too (https://github.com/Goldfish64/AudioPkg), so it can listen to your environment if it wants, at least in theory.
A few thoughts: yes, UEFI is a large attack surface. Secure Boot mitigates a lot of that - if it's turned on, the vast majority of UEFI functionality is only accessible to signed binaries. If you're running untrustworthy code in your boot environment then it's already in a position to just overwrite the firmware, there's no memory protection here. But UEFI doesn't entirely go away after the OS boots, there's some number of runtime services left that the OS depends on. http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html is a demonstration that if you're able to modify those then you can compromise the OS. There's also, of course, all the code in SMM which can just do whatever and may have been audited but possibly hasn't been.
But honestly overall BIOS was a bigger concern than UEFI. It's easy to forget, but a lot of the BIOS hooks are still available at runtime - https://github.com/mqudsi/lrmi is an interface that lets you call them from Linux. It's reasonable to worry about the attack surface exposed by UEFI runtime services, but BIOS software interrupts are frankly even weirder. The reason we largely didn't worry about them is that you normally have to be root to call them, which is also the case for UEFI runtime services and most SMM interfaces. And SMM definitely predates UEFI, so getting away from UEFI complexity wouldn't save us there.
And there's been plenty of meaningful security work done in the UEFI space lately. There's support for proper IOMMU setup so that you can boot off Thunderbolt without any Thunderbolt device just being able to DMA all over your firmware. The NX bit is supported. There's support for stack canaries. There are best practices for SMM behaviour. https://uefi.org/sites/default/files/resources/UEFI%20Firmwa... covers a bunch of this.
If we were designing firmware for maximum security then I don't think anyone would argue we'd come up with UEFI. That doesn't mean that we should be nostalgic about BIOS, which was a smaller attack surface but provided no meaningful security.