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.