Skip to content

Conversation

@tylerfanelli
Copy link
Member

No description provided.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
In the scenario that multiple containers are running with krun-nitro,
hardcoded vsock port identifiers within the host's CID namespace will
result in collision since only one VM can use a single port at a time.

To avoid this, identify vsock port numbers based on an enclave's CID,
which is guarenteed to be unique. This can help reduce collisions.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
@tylerfanelli tylerfanelli changed the title nitro: Add shutdown status reader, signal handling proxy, device modularization, and reorganization nitro: Add CID-specific vsock ports, shutdown status reader, signal handling proxy, device modularization Jan 21, 2026
@tylerfanelli tylerfanelli force-pushed the nitro-shutdown branch 2 times, most recently from 982adc0 to 164e707 Compare January 22, 2026 02:23
We're defining a "device" as an outside service provided by
libkrun-nitro to a nitro enclave. At time of writing, this includes the
arguments writer, network proxy, and output proxy.

Most device proxies will likely have the same behavior. That is, they
run for the lifetime of the enclave and must exit when either signaled
internally (within the enclave) or externally (by libkrun-nitro itself).

Given this shared behavior, implement a DeviceProxy trait that will
allow proxies to share this behavior.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
To organize each the configurable device proxies provided to an enclave,
collect them all into one list.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Besides the standard launch environment arguments written to the
enclave, device proxy configuration arguments can also be written (if
the proxy itself is enabled).

Along with the launch environment, also add enclave arguments to the
writer from the device proxy list.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Delegate all device proxy management to the device list, which can
spawn and manage multiple threads to provide device proxy services.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Upon application exit, the enclave will open a vsock connected to the
host and write a 4-byte buffer (corresponding to the application's
return code) to the enclave.

This also serves as the "shutdown signal" to the host, indicating that
the enclave is exiting.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Organize all of the device proxies into one module.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
Copy link
Member

@jakecorrenti jakecorrenti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left notes for future reference

return 0;
}

ret = ioctl(fd, IOCTL_VM_SOCKETS_GET_LOCAL_CID, &cid);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocker: we could just immediately close the fd after the ioctl call. would let us avoid writing it twice

Net = 2,
AppOutput = 3,

// Not set by krun-nitro.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocker: I think it would be helpful to put the link to the docs where you found this so it's easy for contributors to find the reference materials

@@ -0,0 +1,5 @@
// SPDX-License-Identifier: Apache-2.0

mod devices;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocker: I'm not thrilled about the name since we're not really implementing any device emulation... I don't have a better name, though.

(proxy module maybe?)

.map(|s| s.to_string())
.collect();

args.append(&mut vec![
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocker: rather than defining args at the top of the function and then appending an entire vec right here, just wait to define the variable until after we define argv and envp and just do let mut args = vec![...]

ret = app_status;
break;
// Allow the host to read the return code before exiting the enclave.
sleep(1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocker: wonder if there's a way to handle this without doing a sleep

With long-running applications (e.g. web servers), users will usually
terminate the process by sending a SIGTERM signal to the application.
Since processes running within enclaves are not controlled by the host
OS, the host OS cannot directly send a signal for them to terminate.

Implement a signal forwarder (via vsock) for krun-nitro applications.
This is done by adding a signal handler device proxy within the enclave
that reads 4-byte messages via vsock. These messages are interpreted as
signals from the host to the krun-nitro application. In effect, this
allows host signals to be forwarded to a nitro enclave.

At present, only SIGTERM is supported to signal applications running
within enclaves to gracefully shut down.

Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
@tylerfanelli tylerfanelli merged commit 1a9a548 into containers:main Jan 22, 2026
11 checks passed
@tylerfanelli tylerfanelli deleted the nitro-shutdown branch January 22, 2026 03:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants