qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] sanitize memory on system reset


From: Peter Lieven
Subject: Re: [Qemu-devel] [RFC] sanitize memory on system reset
Date: Thu, 13 Jun 2013 21:20:20 +0200

Am 13.06.2013 um 17:51 schrieb Markus Armbruster <address@hidden>:

> Peter Lieven <address@hidden> writes:
> 
>> On 13.06.2013 12:55, Markus Armbruster wrote:
>>> Peter Lieven <address@hidden> 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.
>> so you would vote for not touching it or at least enable it only through
>> a cmdline paramter?
> 
> If you can demonstrate practical advantages of clearing memory, we can
> talk about how to best do it, and whether it really needs to be
> optional.

i was thinking of 2 things:

a) after some runtime the RSS size of a vServer grows up to its physical memory 
size. on a reset
we could zero out and free the memory.

b) one could think of attack scenario where an attacker has access to a vServer 
management
console but not to the physical vServer node or the vServer itself. in this 
case the attacker could hard reset the
vServer and boot a small rescue system and recover data from the vServer such 
as keys or other
sensitive data. if the memory is zeroed out this can be avoided. a common 
suggestion to mitigate
such attacks is to enable memory power on self-test because it overwrites the 
memory.

Peter





reply via email to

[Prev in Thread] Current Thread [Next in Thread]