On 05/06/20 14:48, email@example.com wrote:
My idea is to implement an UEFI runtime driver that can receive a command via TCP during runtime, then runs a job and finally sends the result back via TCP.I don't see how this could (usefully) work.
You say "UEFI runtime driver", which implies you would do the above with
the operating system running.
But if the OS is already running, then it owns the networking hardware.
Even if the OS does not have a driver for the NIC in question, the OS
certainly owns the "namespace" for the local endpoints of TCP
connections (namely the OS assigns the IP addresses and the port
numbers). I don't see how that could be co-ordinated between a UEFI
runtime driver and the OS.
Another issue would be packet reception. How would the driver notice
incoming packets? UEFI does not handle interrupts (it has no support for
interrupt-driven event loops), and there are no runtime services that
would let you construct a polling loop.
I'm not saying an "SMM rootkit with network connectivity" cannot be
written, but that's not exactly oriented towards cooperation with the OS.
Non-malicious UEFI network drivers are boot time only drivers, and they
have one purpose: enabling booting the OS (or OS bootloader) over the
UNDI is a lower-level abstraction than UEFI. UEFI can use UNDI for
network connectivity (NetworkPkg/SnpDxe does that; it implements the
Simple Network Protocol on top of UNDI), but said "UEFI binding" of UNDI
is again boot time only.