From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWJ2O-0008Ss-SK for qemu-devel@nongnu.org; Mon, 31 Aug 2015 02:57:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWJ2J-0004qq-FD for qemu-devel@nongnu.org; Mon, 31 Aug 2015 02:57:52 -0400 Received: from mga09.intel.com ([134.134.136.24]:43757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWJ2J-0004qh-96 for qemu-devel@nongnu.org; Mon, 31 Aug 2015 02:57:47 -0400 References: <1439563931-12352-1-git-send-email-guangrong.xiao@linux.intel.com> <1439563931-12352-15-git-send-email-guangrong.xiao@linux.intel.com> <20150825162327.GG8344@stefanha-thinkpad.redhat.com> <55DD990B.80204@linux.intel.com> <20150828120155.GO4917@stefanha-thinkpad.redhat.com> From: Xiao Guangrong Message-ID: <55E3F986.1020708@linux.intel.com> Date: Mon, 31 Aug 2015 14:51:50 +0800 MIME-Version: 1.0 In-Reply-To: <20150828120155.GO4917@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 14/18] nvdimm: support NFIT_CMD_IMPLEMENTED function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, Stefan Hajnoczi , mtosatti@redhat.com, qemu-devel@nongnu.org, imammedo@redhat.com, pbonzini@redhat.com, rth@twiddle.net On 08/28/2015 08:01 PM, Stefan Hajnoczi wrote: > 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. > Completely agree with you. :) How about use exit{1} instead of abort() to kill the VM?