Hello everyone,

I am a student working on a project with EDK2 (and qemu), however I am quite new to this topic.

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.
So far I implemented a simple runtime driver, but the network part is missing.
According to the docs [1], I need to implement the UNDI feature and interact with the emulated NIC [2].
The problem is, I cannot find any documentation or code, how I would implement it.
Do you know where I would find some good resources or examples?

Also, I am not sure, if my idea would work that way?
Can a UEFI driver receive TCP packages on a predefined port or can it only send packages?
If not, is there any other way I could trigger a job remotly during runtime so that my driver runs the job and sends the results via TCP?

Thank you for your help and excuse me if my questions are very low-level, but as I said, I am still new to this topic.

Best regards,
Florian Hantke

[1] https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines
[2] https://github.com/tianocore/tianocore.github.io/wiki/EDKII-Network-Over-QEMU

Have you looked at:

https://github.com/tianocore/edk2-libc


Best Regards,
Wim Vervoorn

Thank you, I will check it out.
I only looked through the mian edk2 git, yet.

Best regards,
Florian Hantke

Florian --

Making a runtime driver would be quite difficult, since almost all services are no longer available after ExitBootServices is called by the booting OS.

Perhaps a shell app would be more appropriate, since this runs in the pre-OS.

I'm not a QEMM expert, but I believe that it supports an emulated NIC driver that uses the host's NIC.

Tim

On 05/06/20 14:48, florian.hantke@... 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
network.

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.

Laszlo