On Wed, Aug 26, 2015 at 06:46:35PM +0800, Xiao Guangrong wrote:
> On 08/26/2015 12:23 AM, Stefan Hajnoczi wrote:
> >On Fri, Aug 14, 2015 at 10:52:07PM +0800, Xiao Guangrong wrote:
> >> static void dsm_write(void *opaque, hwaddr addr,
> >> uint64_t val, unsigned size)
> >> {
> >>+ struct MemoryRegion *dsm_ram_mr = opaque;
> >>+ struct dsm_buffer *dsm;
> >>+ struct dsm_out *out;
> >>+ void *buf;
> >>+
> >> assert(val == NOTIFY_VALUE);
> >
> >The guest should not be able to cause an abort(3). If val !=
> >NOTIFY_VALUE we can do nvdebug() and then return.
>
> The ACPI code and emulation code both are from qemu, if that happens,
> it's really a bug, aborting the VM is better than throwing a debug
> message under this case to avoid potential data corruption.
abort(3) is dangerous because it can create a core dump. If a malicious
guest triggers this repeatedly it could consume a lot of disk space and
I/O or CPU while performing the core dumps.
We cannot trust anything inside the guest, even if the guest code comes
from QEMU because a malicious guest can still read/write to the same
hardware registers.
Stefan
