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: Alexander Graf
Subject: Re: [Qemu-devel] [RFC] sanitize memory on system reset
Date: Fri, 14 Jun 2013 11:44:11 +0200


Am 14.06.2013 um 08:56 schrieb Christian Borntraeger <address@hidden>:

> 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

Legacy 286 protected mode to real mode switching also happens through the CPU 
reset PIN, so there certainly is a need to distinguish.

Alex

> 
> 
> 



reply via email to

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