Hey, Respect for not fearing to question the status quo and thinking outside of the box. I am on an SME on that particular topic, so please take my comments with a grain of salt. On Sat, 9 May 2026 at 23:00, Michael Still <mikal@stillhq.com> wrote:
So what might a safer approach look like? My answer is to try and offload the processing of untrusted data to the virtual machine implementation in silicon -- it has strong separation guarantees and it can be orchestrated so that there is simply no access to anything not required for the strict processing of the image. So for example no access to a file system, a network, and so forth. Specifically, what if processing this untrusted and potentially malicious data was done as a KVM guest with a custom virtual machine manager (VMM)?
So I wrote it, and by "I wrote it" I mean Claude Code mostly wrote it. Instar is a from scratch rethink of how to handle
For me a statement like this is unfortunately not a quality stamp. While playing around with AI agents I ensured myself that AI does not take care about future maintenance of the code. It proposes the solution to your question (depending on how you ask it) using the statistics - it is not a secret that current AI is nothing else rather than just a statistical probability machine. I have no problem with asking the AI for support but a statement "Claude mostly wrote it" is not a great signal. I recommend you not to use such phrasing if you want to reach acceptance.
untrusted image data as well as an opportunity for me to become more familiar with code generation LLMs. All data processing happens in a custom KVM guest which does not run an operating system or have any access to system resources apart from those provided to it by the custom VMM which orchestrates it. The best way to think of this guest is as an embedded system running on a virtual CPU. This is similar in approach to how AWS Nitro Enclaves work in terms of prior art, whilst also being the opposite in intent: Nitro protects sensitive data *from* the cloud; instar protects the cloud *from* malicious data. To be clear, `instar info` doesn't detect or block malicious images -- it processes them safely and reports what it finds. The security comes from containment, not detection. It is then up to the caller to decide how to handle what is reported.
I think the proper strategy would be to do both: protect images from the cloud (confidential computing) and cloud for the image. Nitro (all of them) are giving very useful hints about what could and should be done and we definitely should learn from competitors.
At the moment I'd describe Instar as a "vigorous prototype". It implements `qemu-img info` and most of `qemu-img convert`, but does not yet know how to resize, rebase, snapshot, and so forth. I'd be interested in whether other people think this is an interesting idea or not, although honestly it was just kind of fun to build over the summer holidays. I'd particularly welcome
I like the statement: "was just kind of fun over ...". Many in the community are desperately frustrated about more and more maintenance work with less and less people. We should ensure that at least this work is fun, otherwise people just burn out or give up.
feedback on whether this approach would be useful for your deployment, examples of images that produce unexpected results, and thoughts on the daemon / protobuf interface idea.
I definitely support the gRPC introduction. I am already using it in keystone-rs for adding raft support. Also I plan to expose the Keystone API also over gRPC so that control plane communication may benefit from it (not sure whether gRPC for OpenStack public API is a great thing though). Actually the idea of using gRPC in OpenStack is not new and some people were already playing around with this idea nearly 10 years ago. I also agree with your arguments why Rust is a great fit here. Great work, Artem