[vbox-dev] Memory initialization

b38911 Zxc b38911 at gmail.com
Wed Jul 31 16:29:56 GMT 2019


Hello Michal.

yes, good point. I did some tests and I obtained some mixed results, but at
the end, the behavior looks like:
- if I stop the boot at firmware and I dump the memory, no artefacts are
there
- if I continue the boot, sometimes artefacts appears in memory. So it
looks like it's a kind of caching of the operating system at this point.

It is not the "fast boot" option, which I already checked, so it's probably
something else. I need to dig on this.
Anyway, thanks for your help.




Il giorno mer 31 lug 2019 alle ore 16:01 Michal Necasek <
michal.necasek at oracle.com> ha scritto:

>
>  What does "shutdown the guest system/start again the guest system" mean?
> Shut down the VM and start it again? Or reboot the guest OS without
> terminating the VM?
>
>  In either case, I'd recommend dumping the VM's memory right after the VM
> is reset (when it's executing firmware). Are the artifacts there at that
> point?
>
>  Running with --dbg just shows the VM debugger UI, it does not change the
> VM's behavior.
>
>        - Michal
>
> ----- Original Message -----
> From: b38911 at gmail.com
> To: michal.necasek at oracle.com
> Sent: Tuesday, July 30, 2019 11:13:05 AM GMT +01:00 Amsterdam / Berlin /
> Bern / Rome / Stockholm / Vienna
> Subject: Re: [vbox-dev] Memory initialization
>
> Hi Michal.
>
> Sure, I'll try to explain better what I mean:
>
> - start virtualbox and start a Windows 10 guest system (allocating let's
> say 4GB of RAM)
> - start a specific software in the guest, which, after its exits, leave
> some artefacts in RAM (like a specific portion of code in unallocated
> memory). So far, so good, nothing strange.
> - shutdown the guest system
> - start again the guest system
> - looking into the RAM (dumping it), I still see the same artefacts, even
> if I didn't ran the same software as before. Like if the allocated RAM
> (still 4GB) was not re-initialized to 0
>
> This make sense if the initial allocation does not set memory to 0 (or
> something else), since I'm not rebooting the host, so for sure these
> artefacts are still in the host memory.
> If you say that this is reset should be done, I'll try to re-run a set of
> tests, may be I'm missing something. Consider that I'm running the VM with
> --dbg option, not sure if this change something.
>
> Thanks and let me know if you need more details on this.
> Thanks
> c
>
> Il giorno mar 30 lug 2019 alle ore 10:11 Michal Necasek <
> michal.necasek at oracle.com> ha scritto:
>
>>
>>   Can you provide a simple reproduction scenario? What does one have to
>> do to see this?
>>
>>   A VM reset should clear memory. A caveat is that a given guest OS may
>> not perform a full reset but only a soft reboot, which does not clear
>> memory.
>>
>>      - Michal
>>
>> On 7/28/2019 10:15 PM, b38911 wrote:
>> > Hello all.
>> >
>> > I was suggested to post my question here.
>> >
>> > Here my doubt:
>> >
>> > I noticed this behavior, which is probably expected: dumping the RAM of
>> > a guest (with ".pgmphystofile" command) I saw that the memory is not
>> > initialized between virtual powercycle, like if there was a real
>> > powerdown. Sometimes, between restarts of the guest (with a shutdown
>> and
>> > then a restart), I find some memory artifacts belonging to processes
>> > that shouldn't be there.
>> > I assume this happens because I'm not restarting the host system, so
>> > probably the RAM is just remapped, but not initialized. This is a bit
>> > annoying in some case, especially if you are using the system for
>> > testing purposes.
>> >
>> > Is there a way to force the guest to initialize the allocated RAM to
>> > zero (or something else), in order to emulate a real powerdown-powerup?
>> > Thanks for your help.
>> >
>> > cips
>> >
>> > _______________________________________________
>> > vbox-dev mailing list
>> > vbox-dev at virtualbox.org
>> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20190731/109291fc/attachment.html>


More information about the vbox-dev mailing list