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

[H. Peter Anvin]

Only on a real 286.  At least since 486 the legacy switch has been INIT, not 
RESET.

Alexander Graf <address@hidden> wrote:

>
>
>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
>
>> 
>> 
>> 

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.