raising an issue rather than turning up unannounced in a PR
microvms put a hardware-level wall between an agent's workload and the machine it's running on. The design goal is preventative: give the agent its own tiny operating system to play in, and make sure that even if something inside it goes badly wrong - malicious code is run - it can't spill over into the host or any other tenants sharing the same hardware.
It's the right tool when running untrusted workloads or multi-tenant workloads and you need confidence that one tenant's bad day doesn't become everyone's bad day. For the threat model is "an agent might run arbitrary code and try to break out of its box," Firecracker / gVisor are best in class.
nono addresses a different threat - how do we introduced fine grained capability based isolation within the agents operating context - agents need to be delegated authority, they sometimes need access to certain files or credentials to perform their role - nono provides that level of fine grained isolation using kernel primitives, so it composes well with microvms and is not seeking to replace.
I am happy to prototype here and put something up for the community review - we may be able to leverage the nono cli / runtime component, which means limited code changes in substrate tree
It would likely need #123 landing first, as only firecracker is capable of running landlock and its not available in gvisor.
before I do anything though, I woulkd like to know how receptive the community maybe to this , and hear out any objections early on.
raising an issue rather than turning up unannounced in a PR
microvms put a hardware-level wall between an agent's workload and the machine it's running on. The design goal is preventative: give the agent its own tiny operating system to play in, and make sure that even if something inside it goes badly wrong - malicious code is run - it can't spill over into the host or any other tenants sharing the same hardware.
It's the right tool when running untrusted workloads or multi-tenant workloads and you need confidence that one tenant's bad day doesn't become everyone's bad day. For the threat model is "an agent might run arbitrary code and try to break out of its box," Firecracker / gVisor are best in class.
nono addresses a different threat - how do we introduced fine grained capability based isolation within the agents operating context - agents need to be delegated authority, they sometimes need access to certain files or credentials to perform their role - nono provides that level of fine grained isolation using kernel primitives, so it composes well with microvms and is not seeking to replace.
I am happy to prototype here and put something up for the community review - we may be able to leverage the
nonocli / runtime component, which means limited code changes in substrate treeIt would likely need #123 landing first, as only firecracker is capable of running landlock and its not available in gvisor.
before I do anything though, I woulkd like to know how receptive the community maybe to this , and hear out any objections early on.