On Mon, Oct 22, 2018 at 11:05:13AM -0700, Greg Steuck wrote:
> Hi Reyk & Anton,
>
> I upgraded the syzkaller machine from Oct 11 to Oct 21 snapshot and started
> seeing:
> Oct 22 10:00:21 ci-openbsd vmd[15707]: qc2_open: missing base image
> /syzkaller/managers/main/current/image
> Oct 22 10:00:21 ci-openbsd vmd[15707]:
> /syzkaller/managers/main/current/image: could not open qc2_open: No such
> file or directory
> Oct 22 10:00:21 ci-openbsd vmd[13268]: qc2_open: missing base image
> /syzkaller/managers/main/current/image
> Oct 22 10:00:21 ci-openbsd vmd[13268]:
> /syzkaller/managers/main/current/image: could not open qc2_open: No such
> file or directory
> Oct 22 10:00:21 ci-openbsd vmd[51186]: qc2_open: missing base image
> /syzkaller/managers/main/current/image
> Oct 22 10:00:21 ci-openbsd vmd[51186]:
> /syzkaller/managers/main/current/image: could not open qc2_open: No such
> file or directory
>
> Reverting the change in subject and rebuilding vmd&vmctl stops the problem.
>
> The file in question exists:
> ci-openbsd$ file /syzkaller/managers/main/current/image
> /syzkaller/managers/main/current/image: QEMU QCOW Image (v3), 1073741824
> bytes
> ci-openbsd$ ls -l /syzkaller/managers/main/current/image
> -rw-r----- 2 syzkaller syzkaller 545783808 Oct 22 10:34
> /syzkaller/managers/main/current/image
>
> Under the hood this command line is executed:
> vmctl start ci-openbsd-main-0 -b /syzkaller/managers/main/current/kernel -d
> /syzkaller/managers/main/workdir/instance-0/disk.qcow2 -m 512M -L -c -t
> syzkaller
>
> Anton, what does your code is syzkaller do to create this file?
> -rw------- 1 syzkaller syzkaller 262144 Oct 22 10:59
> /syzkaller/managers/main/workdir/instance-0/disk.qcow2
>
>
> The file does reference the base image:
> ci-openbsd$ strings /syzkaller/managers/main/workdir/instance-0/disk.qcow2
>
> h/syzkaller/managers/main/current/image
>
> Thanks
> Greg
> --
> nest.cx is Gmail hosted, use PGP for anything private. Key:
> http://goo.gl/6dMsr
> Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
I'm also not able to start a VM using a derived disk after this commit.
It looks to me like the code is trying to resolve the base disk for the
derived disk over and over instead of walking down the chain of derived
disks. This causes file descriptors to be opened only for the derived
disk whereas the base disk is expected. With the diff below, I'm able to
boot using a derived disk again.
Index: config.c
===================================================================
RCS file: /cvs/src/usr.sbin/vmd/config.c,v
retrieving revision 1.53
diff -u -p -r1.53 config.c
--- config.c 19 Oct 2018 10:12:39 -0000 1.53
+++ config.c 24 Oct 2018 15:48:00 -0000
@@ -364,6 +364,10 @@ config_setvm(struct privsep *ps, struct
base, vcp->vcp_disks[i]);
goto fail;
}
+ if (strlcpy(path, base, sizeof(path)) >= sizeof(path)) {
+ log_warnx("%s, base path too long", __func__);
+ goto fail;
+ }
}
}
