docs(rfc): add RFC 0013 native Windows support via MXC#2071
docs(rfc): add RFC 0013 native Windows support via MXC#2071shailendra-nv wants to merge 1 commit into
Conversation
Propose native Windows 11 support through a build-only MSVC lane and a new in-process, supervisor-free MXC compute driver, with host-side governed egress and an OpenShell to MXC policy-translation seam. Refs: NVIDIA#2050 Signed-off-by: Shailendra Singh <shailendras@nvidia.com>
shailendra-nv
requested review from
a team,
derekwaynecarr,
maxamillion and
mrunalp
as code owners
|
Thank you for your submission! We ask that you sign our Developer Certificate of Origin before we can accept your contribution. You can sign the DCO by adding a comment below using this text: I have read the DCO document and I hereby sign the DCO. You can retrigger this bot by commenting recheck in this Pull Request. Posted by the DCO Assistant Lite bot. |
|
|
||
| This RFC proposes extending OpenShell to run natively on Windows 11 (x64 and | ||
| ARM64) without a Linux VM, Docker Desktop, or WSL. It will produce a new | ||
| compute driver, `openshell-driver-mxc`, that will use Microsoft |
There was a problem hiding this comment.
Yes, I think that would be preferred if possible.
Thinking out loud here: If we used an out-of-tree remote driver and were able to use the containerized gateway, our only windows build target would be the CLI.
I have read the DCO document and I hereby sign the DCO. |
|
recheck |
| The defining property is that the OpenShell value layers — egress policy, L7 | ||
| inspection, inference routing, and the privacy router — live on the host inside | ||
| the gateway process, not inside the sandbox. A native Windows agent therefore |
There was a problem hiding this comment.
Would this defining property still be valid if the supervisor was run only in networking mode? This essentially deploys the supervisor exclusively as the proxy.
There was a problem hiding this comment.
The proxy also assumes it's serving exactly one sandbox. Does this design imply that there will be a many:1 ratio of sandboxes-to-proxy?
There was a problem hiding this comment.
Would this defining property still be valid if the supervisor was run only in networking mode? This essentially deploys the supervisor exclusively as the proxy.
Yes. The defining property is about the location of enforcement which would be host rather than sandbox itself due to lack of fine grained network enforcement in MXC. The idea here is that we extend the network enforcement with host side proxy.
There was a problem hiding this comment.
The proxy also assumes it's serving exactly one sandbox. Does this design imply that there will be a many:1 ratio of sandboxes-to-proxy?
Correct that's the design intent. As we have a host side proxy rather than supervisor per sandbox, it was kept Many:1 with sandbox attribution to reduce the host side overhead. We can look into 1:1 implementation with shared pieces reused with host side proxy. In a client system, I am worried about the resource cost for such implementation.
| - Porting `openshell-sandbox` (the Linux supervisor) to Windows, or shipping any | ||
| in-sandbox OpenShell binary. Defense-in-depth via an in-sandbox enforcer | ||
| is explicitly deferred. |
There was a problem hiding this comment.
Is it deferred, or rejected? If it's deferred when do we see us picking it up? The current proposal is a large architecture change w.r.t the supervisor, so I don't want to unwind this change down the road if we want to eventually port the sandbox.
| - Making Windows a Docker, Podman, Kubernetes, or VM runtime host. Those drivers | ||
| remain compile-only configuration stubs that return an unsupported error. |
There was a problem hiding this comment.
Why not include Docker which does work on Windows?
There was a problem hiding this comment.
Docker on Windows uses Docker Desktop -- which uses a WSL2-backed VM to actually run the containers. This runs LINUX containers.
| The `mxc.rs` invoker is the boundary to MXC. Invocation is always | ||
| `wxc-exec.exe --config-base64 <base64(JSON)> --experimental [--debug]`; | ||
| `configurationId` defaults to `composable` (never `small` — a known OS bug). The | ||
| invoker must branch on phase for I/O semantics: |
There was a problem hiding this comment.
Today, sandboxes are represented as a container and can be built from Dockerfiles. Eg I can run openshell sandbox create --from my.Dockerfile.
How are we handling this from the MXC driver? If starting sandboxes from container images aren't supported, how is software made available to the sandbox? Is everything shared w/ the host?
| #### State model and lifecycle | ||
|
|
||
| MXC has no remote inventory API, so the in-memory registry is the single source | ||
| of truth. |
There was a problem hiding this comment.
Is there a reconciliation loop? Eg if I directly delete an OpenShell managed appcontainer, will that get reflected in OpenShell?
| The driving constraint is that MXC network filtering is host/IP/CIDR-level only: | ||
| it cannot encode ports, protocols, per-binary scope, or L7 rules. The mapper | ||
| therefore emits the coarsest safe approximation and a structured loss report. |
There was a problem hiding this comment.
What is the coarsest approximation? Does this mean you are mapping OpenShell network policies to MXC network policies?
4 participants
Summary
Adds RFC 0013, which proposes running OpenShell natively on Windows 11 (x64 and ARM64) without a Linux VM, Docker Desktop, or WSL. The proposal introduces a new
openshell-driver-mxccompute driver built on Microsoft Execution Containers (MXC /wxc-exec) and relocates OpenShell's value layers (egress policy, L7 inspection, inference and privacy routing) to a host-side CONNECT proxy, avoiding any in-sandbox supervisor on Windows.Related Issue
Refs #2050
Changes
rfc/0013-native-windows-mxc/README.md(RFC 0013, state:review).openshell-driver-mxccompute driver backed bywxc-exec.wxc-execbinary.block, never silently broaden) mapper, plus design decisions D1-D4, risks, and alternatives.Testing
mise run pre-commitpassesChecklist