On 18/05/2026 14:45, Dan Smith wrote:
I did ponder libguestfs along the way. The big difference, at least to my understanding, is that libguestfs runs a linux kernel in its KVM guest with an associated small operating system, and then uses standard command line tools to service requests. Instar is more like a unikernel than libguestfs in the sense that instar _does_ not run a kernel as we think of it, and has no userspace. Instar is more like having the qemu-img operations performed on a service processor that just happens to be an x86 virtual core if that makes sense. I think that makes the security posture (and complexity) of the two quite different. Okay I guess I'm not sure that's really a mark in favor of "more secure" to me. It certainly /could/ be so, and a massively smaller stack /could/ mean a smaller surface area. If it were something highly cultivated and scrutinized perhaps, but just running something on "bare metal" that was largely output that we didn't review/understand at every level doesn't really ring the bell for me. Definitely interesting and cool though :) for what it worth i think the image inspector work in oslo effectivly mitigates much of the securtiy concern of invoking qemu-image or other tools to do things like resize/format conversion as we have effecctivly promoted the image form untrusted to trusted. now its also true that unless we reject images with featuer we do not have knowldage of there is a bit of an arms race between preventing a unsafe feature from being used and updating it but we can ligitiamtly do that
i.e. look at teh image and say your enableing a feature we dont know about and reject that means that any iamge we are passing to qemu-image is know safe and at that point qemu-iamge is nolonger in the critial path to protect the cloud form its users. the oslo.utils approch si never executing anythign its just parsing the bytes of the straem so its much much safer then qemu-image in that regard and its inhernetly portable without a depency on kvm or similar so my current expectation fo how we are eveoling this is not to fined a better way to handel untrusted disk tehn qemu-img its ot make sure we never pass an untrusted disk to qemu-image. dan has been leading much of the work on that and the Glance as the defender work but that context is relevnet to evaulating qemu-image alternitives. the qemu-image maintainer have told us to not rely on it for untursted images so dan and other have been tryign to make sure we have validated the image before we ever do that so its nolonger untrusted. it may still be user supplied but thos are two diffent thigns.
If you discount moving pages around in memory, which I think all inspection tools would have to do, instar does not copy the input data prior to inspection. I'm not talking about copying pages in memory: what I meant is that glance does not ever need to store the image on disk while it's being uploaded in order to inspect it. If you back glance with swift and upload a qcow2, we never store it on disk first, inspect, and then upload to swift (aside from the import workflow that does that incidentally). We look at the stream _as_ it's being proxied to swift (or rbd, or whatever else) and we can abort the upload after you've send a few KiB, we know it's qcow2 and we know it's bad.
yep that a very nice capablity and sideefect of the way the image inspector is stream based. for some format we unfortuently do need to process the stream of the entire disk to determin if its safe but for many formats we only need the first few bytes and we can bail early if we ever detect its invailed without processign the rest.
--Dan