From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59336)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1Un3uY-0006Bh-RB
	for qemu-devel@nongnu.org; Thu, 13 Jun 2013 05:33:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1Un3uV-0006TP-W6
	for qemu-devel@nongnu.org; Thu, 13 Jun 2013 05:33:42 -0400
Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:51466 helo=mx01.kamp.de)
	by eggs.gnu.org with smtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1Un3uV-0006TG-Ly
	for qemu-devel@nongnu.org; Thu, 13 Jun 2013 05:33:39 -0400
Message-ID: <51B991F4.5000405@kamp.de>
Date: Thu, 13 Jun 2013 11:33:40 +0200
From: Peter Lieven <pl@kamp.de>
MIME-Version: 1.0
References: <51B96205.4010601@kamp.de> <51B98F70.3070009@suse.de>
In-Reply-To: <51B98F70.3070009@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC] sanitize memory on system reset
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 13.06.2013 11:22, Andreas Färber wrote:
> Hi,
>
> Am 13.06.2013 08:09, schrieb Peter Lieven:
>> I was thinking if it would be a good idea to zeroize all memory
>> resources on system reset and
>> madvise dontneed them afterwards.
> The current way of not zeroing memory has led to discovery of some
> firmware bugs that we wouldn't have found if QEMU defaulted to zeroing.
The memory is zero at the start due to the use of mmap. Maybe
we need to add an option to add an initialization value anyway
because I am unsure if PERTURB works with mmap?!
>
>> 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.
> Apart from the guest issue Stefan brought up (so far by definition we do
> a hard reset, so guests cannot assume soft reset semantics, but we
> should keep our options open), would not zeroing while marking pages as
> unused be an option? E.g., -reset-memory=DEADBEEF or some other
> command-line-specifiable pattern, absence would mean current behavior.
This would overwrite all contents with 0xdeadbeaf avoiding information
leak, but it would unnecessarily keep the memory alocated. So what
about an option -mem-sanitize with an optional parameter to write
a initialization value.

option missing -> no change
-mem-sanitize -> zeroize and madv_dontneed
-mem-sanitze=deadbeaf -> fill memory with 0xdeadbeaf

Where is the right postion to add this hook. qemu_system_reset() ?

Peter
>
> Regards,
> Andreas
>


-- 

Mit freundlichen Grüßen

Peter Lieven

...........................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

...........................................................