From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnNvo-0003z3-UP for qemu-devel@nongnu.org; Fri, 14 Jun 2013 02:56:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnNvn-0002bA-IC for qemu-devel@nongnu.org; Fri, 14 Jun 2013 02:56:20 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:54628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnNvn-0002at-9E for qemu-devel@nongnu.org; Fri, 14 Jun 2013 02:56:19 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Jun 2013 07:49:16 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9C02E17D8025 for ; Fri, 14 Jun 2013 07:57:37 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5E6u4jW56033340 for ; Fri, 14 Jun 2013 06:56:04 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r5E6uEhO003432 for ; Fri, 14 Jun 2013 00:56:15 -0600 Message-ID: <51BABE8D.1040103@de.ibm.com> Date: Fri, 14 Jun 2013 08:56:13 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <51B96205.4010601@kamp.de> <20130613084015.GF2633@stefanha-thinkpad.redhat.com> <51B98822.1030402@kamp.de> <8761xi7016.fsf@blackfin.pond.sub.org> <87vc5iz0j8.fsf@codemonkey.ws> In-Reply-To: <87vc5iz0j8.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] sanitize memory on system reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" , Stefan Hajnoczi , Peter Lieven , Alexander Graf , Markus Armbruster , "H. Peter Anvin" On 13/06/13 13:56, Anthony Liguori wrote: > Markus Armbruster writes: > >> Peter Lieven writes: >> >>> On 13.06.2013 10:40, Stefan Hajnoczi wrote: >>>> On Thu, Jun 13, 2013 at 08:09:09AM +0200, Peter Lieven wrote: >>>>> I was thinking if it would be a good idea to zeroize all memory >>>>> resources on system reset and >>>>> madvise dontneed them afterwards. This would avoid system reset >>>>> attacks in case the attacker >>>>> has only access to the console of a vServer but not on the physical >>>>> host and it would shrink >>>>> RSS size of the vServer siginificantly. >>>> I wonder if you'll hit weird OS installers or PXE clients that rely on >>>> stashing stuff in memory across reset. >>> One point: >>> Wouldn't a memory test which some systems do at startup break these as well? >> >> Systems that distinguish between warm and cold boot (such as PCs) >> generally run POST only on cold boot. >> >> I'm not saying triggering warm reboot and expecting memory contents to >> survive is a good idea, but it has been done. > > Doesn't kexec do a warm reboot stashing the new kernel somewhere in > memory? It does something like that on s390. There is a diagnose instruction to the machine, that resets all subsystems and cpus in a defined state, but lets the memory untouched. So we want to be able to define the components of the system which we are going to reset and have two cases: 1. reset everything and clear the memory 2. just reset the cpus and devices, but leave the memory untouched For case 2 we basically want to avoid memory clearing AND bios reloading