std: sys: net: uefi: tcp: Initial TcpListener support #145339

Ayush1325 · 2025-08-13T07:50:52Z

Add support for binding and accepting TCP4 connections.

While testing, the following network options were used with QEMU + OVMF: -nic user,hostfwd=tcp::12345-:12345

The default localhost address on qemu seems to be 10.0.2.15.

UEFI spec does not seem to state that the TCP Handle returned by the Accept method has a ServiceBinding Protocol. So have made the ServiceBinding Protocol optional.

cc @nicholasbishop

rustbot · 2025-08-13T07:50:57Z

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

ibraheemdev · 2025-08-19T03:52:35Z

Passing this along to someone else, who hopefully has more context. r? libs

Ayush1325 · 2025-08-29T17:00:55Z

@rustbot label +O-UEFI

tgross35 · 2025-09-03T00:19:37Z

Thom is off the review rotation
r? libs

Also gentle ping @nicholasbishop for a review since we usually defer UEFI to you

library/std/src/sys/net/connection/uefi/tcp.rs

library/std/src/sys/net/connection/uefi/tcp4.rs

tgross35 · 2025-09-05T03:17:00Z

library/std/src/sys/net/connection/uefi/tcp4.rs

+            // The spec does not seem to state if we need to call ServiceBinding->DestroyChild for
+            // this handle


Is there a reference implementation that does or doesn't do this? Or a way to check whether or not the handle is valid after this call?

library/std/src/sys/net/connection/uefi/tcp4.rs

bors · 2025-09-11T01:49:09Z

☔ The latest upstream changes (presumably #146418) made this pull request unmergeable. Please resolve the merge conflicts.

phip1611

Generally LGTM but left a few remarks

View changes since this review

library/std/src/sys/net/connection/uefi/mod.rs

library/std/src/sys/net/connection/uefi/tcp4.rs

tgross35

I assume the waiting-on-author label isn't actually accurate?

This LGTM, with the note that if you are following some sort of reference implementation for #145339 (comment) then it would be good to mention what that is in a comment.

You should probably rebase before merge and verify that it still builds, since sys::net has had some changes in recent weeks. Also cc @nicholasbishop if you'd like to double check this.

View changes since this review

tgross35 · 2025-09-24T06:09:52Z

library/std/src/sys/net/connection/uefi/tcp4.rs

+        let completion_token =
+            tcp4::CompletionToken { event: evt.as_ptr(), status: Status::SUCCESS };
+        let mut listen_token =
+            tcp4::ListenToken { completion_token, new_child_handle: crate::ptr::null_mut() };


Should probably just import crate::ptr, it's used a lot of places in this module and will likely wind up in more in the future. (totally optional here ofc)

rustbot · 2025-09-24T06:46:35Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Ayush1325 · 2025-09-24T07:02:00Z

This LGTM, with the note that if you are following some sort of reference implementation for #145339 (comment) then it would be good to mention what that is in a comment.

So, just looked at the internals of edk2 again, and it does seem like I need to use service binding protocol to clean it up. From what I gather of the implementation of TcpServiceBindingDestroyChild, it seems like at least edk2 assumes there to be only one service binding protocol for both tcp4 and tcp6. In fact, no data from service binding protocol is passed or used to destroy the socket (other than then service binding protocol not being null).

So will adjust the PR once I get time.

Ayush1325 · 2025-09-24T08:45:08Z

I am now using the parent service binding protocol to handle in any connections accepted by TCP4. On EDK2, this is not really required, since there seems to be an assumption of a single service binding protocol for both TCP4 and TCP6. However, best to be safe.

I have also refactored service binding wrapper a bit. It's best to cleanup tcp4 protcol handles in it's own drop.

@rustbot ready

Add support for binding and accepting TCP4 connections. While testing, the following network options were used with QEMU + OVMF: -nic user,hostfwd=tcp::12345-:12345 The default localhost address on qemu seems to be 10.0.2.15. UEFI spec does not seem to state that the TCP Handle returned by the Accept method has a ServiceBinding Protocol. So have made the ServiceBinding Protocol optional. Signed-off-by: Ayush Singh <[email protected]>

tgross35

Code LGTM, have a few requests for where the safety invariants live

View changes since this review

tgross35 · 2025-10-03T21:06:57Z

library/std/src/sys/pal/uefi/helpers.rs

+    pub(crate) fn destroy_child(&self, handle: NonNull<crate::ffi::c_void>) -> io::Result<()> {
+        let sbp = open_protocol::<service_binding::Protocol>(self.handle, self.service_guid)?;
+
+        // SAFETY: Child handle must be allocated by the current service binding protocol.
+        let r = unsafe { ((*sbp.as_ptr()).destroy_child)(sbp.as_ptr(), handle.as_ptr()) };
+        if r.is_error() { Err(crate::io::Error::from_raw_os_error(r.as_usize())) } else { Ok(()) }
    }


This needs to be unsafe if the precondition of the destroy_child call depends on the validity of handle.

Also, is it safe to call destroy_child with the same handle more than once?

tgross35 · 2025-10-03T21:13:28Z

library/std/src/sys/pal/uefi/helpers.rs

 pub(crate) struct ServiceProtocol {
    service_guid: r_efi::efi::Guid,
    handle: NonNull<crate::ffi::c_void>,
-    child_handle: NonNull<crate::ffi::c_void>,
 }

 impl ServiceProtocol {
-    pub(crate) fn open(service_guid: r_efi::efi::Guid) -> io::Result<Self> {
+    /// Open a child handle on a service_binding protocol.
+    pub(crate) fn open(
+        service_guid: r_efi::efi::Guid,
+    ) -> io::Result<(Self, NonNull<crate::ffi::c_void>)> {


type Handle = NonNull<crate::ffi::c_void> may be a worthwhile typedef since it's used a few times in this file and in Tcp4

tgross35 · 2025-10-03T21:19:21Z

library/std/src/sys/pal/uefi/helpers.rs

    fn create_child(
        sbp: NonNull<service_binding::Protocol>,
    ) -> io::Result<NonNull<crate::ffi::c_void>> {


Actually I think this needs to be unsafe too for the same reason

tgross35 · 2025-10-03T21:31:09Z

library/std/src/sys/pal/uefi/helpers.rs

+///
+/// SAFETY: Copying ServiceProtocol is safe as long as handle is valid. For most service binding
+/// protocols, at least in edk2 implementations, the lifetime of these handles will be till UEFI is
+/// active, i.e. 'static
+#[derive(Clone, Copy)]
 pub(crate) struct ServiceProtocol {
    service_guid: r_efi::efi::Guid,
    handle: NonNull<crate::ffi::c_void>,
-    child_handle: NonNull<crate::ffi::c_void>,
 }


The SAFETY comment shouldn't be here since duplicating this struct doesn't do anything by itself. If the handle is expected to be valid for 'static, this would be better expressed as an /// Invariant: ... comment on the handle field. Then:

For unsafe calls that use handle, you can say they are valid by the invariant

For places where ServiceProtocol is constructed, you can add an // INVARIANT: comment saying why they meet that invariant. And call out the assumption.

For most service binding protocols, at least in edk2 implementations, the lifetime of these handles will be till UEFI is active, i.e. 'static

Are there cases where a relevant handle here will disappear earlier that we need to worry about?

rustbot assigned ibraheemdev Aug 13, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 13, 2025

Ayush1325 mentioned this pull request Aug 13, 2025

Tracking Issue for uefi-std #100499

Open

rustbot assigned thomcc and unassigned ibraheemdev Aug 19, 2025

rustbot added the O-UEFI UEFI label Aug 29, 2025

rustbot assigned tgross35 and unassigned thomcc Sep 3, 2025

tgross35 requested changes Sep 5, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 5, 2025

Ayush1325 force-pushed the uefi-tcp4-accept branch from 54d3d51 to 5459fc4 Compare September 5, 2025 06:25

phip1611 suggested changes Sep 11, 2025

View reviewed changes

library/std/src/sys/net/connection/uefi/mod.rs Outdated Show resolved Hide resolved

library/std/src/sys/net/connection/uefi/tcp4.rs Outdated Show resolved Hide resolved

library/std/src/sys/net/connection/uefi/tcp4.rs Outdated Show resolved Hide resolved

Ayush1325 force-pushed the uefi-tcp4-accept branch from 5459fc4 to 9f020a9 Compare September 11, 2025 07:09

This comment has been minimized.

Sign in to view

tgross35 approved these changes Sep 24, 2025

View reviewed changes

Ayush1325 force-pushed the uefi-tcp4-accept branch from 9f020a9 to a452682 Compare September 24, 2025 06:46

Ayush1325 force-pushed the uefi-tcp4-accept branch from a452682 to e2521f5 Compare September 24, 2025 08:42

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 24, 2025

Ayush1325 force-pushed the uefi-tcp4-accept branch from e2521f5 to ba446c9 Compare September 24, 2025 08:50

tgross35 requested changes Oct 3, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 3, 2025

		// The spec does not seem to state if we need to call ServiceBinding->DestroyChild for
		// this handle

std: sys: net: uefi: tcp: Initial TcpListener support #145339

Are you sure you want to change the base?

std: sys: net: uefi: tcp: Initial TcpListener support #145339

Conversation

Ayush1325 commented Aug 13, 2025

Uh oh!

rustbot commented Aug 13, 2025

Uh oh!

ibraheemdev commented Aug 19, 2025

Uh oh!

Ayush1325 commented Aug 29, 2025

Uh oh!

tgross35 commented Sep 3, 2025

Uh oh!

Uh oh!

Uh oh!

tgross35 Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bors commented Sep 11, 2025

Uh oh!

phip1611 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

tgross35 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

Ayush1325 Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

rustbot commented Sep 24, 2025

Uh oh!

Ayush1325 commented Sep 24, 2025

Uh oh!

Ayush1325 commented Sep 24, 2025

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

phip1611 left a comment •

edited by rustbot

Loading

tgross35 left a comment •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading