init: optional vsock exec server so OCI runtimes can implement exec and signal delivery

This feature is very much welcome! In fact it's something I've been meaning to implement as well. This https://github.com/libkrun/libkrun/pull/502 unfinished virtio-console work was motivated by a use case like this.

My original idea was to use a separate virtio-console control port, while exec -it would use dynamically-added virtio console ports (shows up as hvcN in the guest):

host PTY <-> virtio-console <-> /dev/hvcN in guest <-> exec'd process

Upon more investigation today, I think vsock is probably better currently. The main issue with the console approach is the current HVC tty allocation limit in the guest kernel and the fact it needs to preallocate many virtio queues for the ports upfront. But still we could possibly design the API so this is just an implementation detail for the user of this.

Regarding your questions:

• I'd say we can have the server as a thread in krun-init for now. I'd be fine with making the control server incompatible with that mode initially and revisiting it if needed. On the other hand a process is fine too, it's just weird for this to not be handled by init process, when we already typically have an init process anyway. (btw KRUN_INIT_PID1 is supposed to move to a proper InitBuilder api method instead of env var.)

• I think we can default to a fixed/private guest vsock port, but make it overridable. This also mean we need to pass the vsock device as an argument to InitBuilder::apply.

• should the exec'd process also get the OCI rlimits/caps or is uid/gid enough?

  Yes I suppose. We should try to mirror normal container semantics if possible. But it's not important to handle in the initial PR.

Also one thing to be careful about with the host control endpoint is AF_UNIX TSI. If KRUN_TSI_FLAGS_HIJACK_UNIX were enabled, a guest process could potentially ask TSI to connect to the host control socket, which would then appear to krun-init as a host-originated vsock connection. So the host-CID check alone isn't sufficient as a long-term security boundary; the control endpoint needs to be unreachable through TSI.

Also regarding your PoC one thing I would really change is is the host-side API/ABI. Right now crun knows the guest port, protocol version, frame IDs, framing, exec request encoding, TTY resize encoding, exit-status encoding, etc. I'd rather keep all of that private to krun-init and expose normal function calls to crun. It also means crun doesn't need to maintain another protocol parser. This is the same idea as with the init configuration json - In libkrun 2.0 the API contract between init-blob on the host and the guest init isn't supposed to be public and can freely change.

For example, I could imagine the API looking roughly like this:

// `state_dir` is crun's already-resolved per-container runtime state
// directory, e.g. $XDG_RUNTIME_DIR/crun/<container-id> with crun's
// rootless default, or under an explicitly configured state root.
let control_socket = state_dir.join("krun-init.sock");

let init = InitBuilder::new()
    // Enabling this also arranges the private guest-vsock <-> host
    // control-endpoint mapping.
    .control_socket(&control_socket)
    // .workload_is_pid1(true)  // incompatible with control service for now
    .build()?;

Then a later crun exec resolves the same per-container state directory and connects to it:

let control_socket = state_dir.join("krun-init.sock");

// Represents the running krun-init, not an individual exec session.
let controller = InitController::open(&control_socket)?;

// NOTE: Initial PR doesn't need to implement all of these,
// this is just illustrative
let request = ExecRequest::builder("/bin/bash")
    .arg("-l")
    .env("FOO", "bar")
    .cwd("/workspace")
    .uid(uid)
    .gid(gid)
    .additional_gids(groups)
    .rlimit(...)
    .build()?;


let process = controller.exec(
    request,
    ExecIO::Pipes(stdout_fd, stdin_fd, stderr_fd),
    // or:
    // ExecIO::Tty(tty_fd)
)?;

process.signal(SIGTERM)?;

let exit_code = process.wait();

// We can also have control commands that are not specific to the payload
controller.signal_entrypoint(SIGTERM)?;

Also for the guest <-> host protocol, since both sides are Rust we should have a shared crate with structs containing serde annotations and use some already existing serialization format instead of implementing it ourselves. (the currently duplicated serde structs for the init config json should also eventually go to the proposed crate).