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: Christian Borntraeger
Subject: Re: [Qemu-devel] [RFC] sanitize memory on system reset
Date: Fri, 14 Jun 2013 08:56:13 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

On 13/06/13 13:56, Anthony Liguori wrote:
> Markus Armbruster <address@hidden> writes:
> 
>> 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.
> 
> 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






reply via email to

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