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 |
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.
2 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