At 04/18/2012 05:23 PM, Daniel P. Berrange Wrote: > On Wed, Apr 18, 2012 at 03:30:04PM +0800, Wen Congyang wrote: >> The command's usage: >> dump [-p] protocol [begin] [length] >> The supported protocol can be file or fd: >> 1. file: the protocol starts with "file:", and the following string is >> the file's path. >> 2. fd: the protocol starts with "fd:", and the following string is the >> fd's name. >> >> Note: >> 1. If you want to use gdb to process the core, please specify -p option. >> The reason why the -p option is not default is: >> a. guest machine in a catastrophic state can have corrupted memory, >> which we cannot trust. > > What is the behaviour of this command if we set '-p', and the guest > is corrupt ? > > If '-p' is not safe when the guest is in a corrupted state, then I'd > argue that '-p' is not safe *ever*, since a malicious guest could > setup bad page maps at any time it likes and we've no way of knowing > this from the host.
Yes, '-p' is not safe, and the default value is false. Someone may use gdb to deal with the vmcore, so '-p' is useful for them. > >> b. The guest machine can be in read-mode even if paging is enabled. >> For example: the guest machine uses ACPI to sleep, and ACPI sleep >> state goes in real-mode. >> 2. This command doesn't support the fd that is is associated with a pipe, >> socket, or FIFO(lseek will fail with such fd). > > How hard would it be to lift that restriction ? When libvirt does save to > file, or core dump these days, we tend to pass a pipe FD to QEMU, which > is connected to libvirt's I/O helper process. The reason for this is that > it lets us turn on O_DIRECT for the dumped data, which has proved to be > quite an important feature for oVirt. So I'd rather like to keep that > ability with the new dump command. The reason is that we will use lseek(fd, ...). If you pass a pipe FD to qemu, lseek() will fail. I donot know the note size before we write it to the core, so I use lseek()... Thanks Wen Congyang > > Regards, > Daniel
