Re: zero-fill and memory allocation size
Re: zero-fill and memory allocation size
- Subject: Re: zero-fill and memory allocation size
- From: Joel Reymont <email@hidden>
- Date: Thu, 10 Dec 2009 20:55:35 +0000
Terry,
Thank you for your extensive comments. I assume you meant to send them to the list.
I was referring to a previous discussion and the 15K mentioned in it. Does that still stand?
Thanks, Joel
[1] http://lists.apple.com/archives/PerfOptimization-dev/2008/Nov/msg00033.html
On Dec 10, 2009, at 8:51 PM, Terry Lambert wrote:
> On Dec 10, 2009, at 11:43 AM, Joel Reymont wrote:
>> I understand that allocations over a certain size come from the virtual memory manager and have to be zero-filled. Is 15K still that size?
>
>
> Assuming this is an allocation by a process:
>
> All processes run in virtual address spaces, so all memory in them comes from the VM system.
>
> Virtual pages in processes are not backed by physical pages until they are used. When this happens, the physical page that gets assigned to the virtual address in the process is zero-filled. Failure to do this could leak sensistive information from the process previously using the physical backing page into the new process. So this is not optional.
>
> Once a physical page is allocated to a virtual page in a process, it can be used by the process. If the process fills it with data, that page contains the data that was put in it.
>
> If a process implementation an allocation/release mechanism, such as malloc/free, or uses a system library that does so, when a page is freed it is not necessarily immediately returned to the system. For some implementations, it is not *ever* returned to the system.
>
> If a process using an allocation/release mechanism allocates memory, dirties it, and releases it, and then makes a subsequent allocation, that allocation may contain the previous data which dirtied the page. This is typical, since zeroing the memory is more expensive than doing nothing, and process itself does not partition security zones, since it only supports a single virtual address space, and so can not protect against accesses by other threads within itself.
>
> Thus you MUST NOT _depend_ on the contents of the memory you allocate being zeroed.
>
> If you need zero-filled memory, you will need to bzero it yourself.
>
> For some memory allocators, you can bzero the memory before freeing; however, other implementations will write their bookkeeping information into the freed memory (for example, free-list pointers in the memory itself to avoid out of band free list memory overhead), so you can not depend on post-use-zeroing-before-freeing memory to cause your allocator to always give you zeroed memory.
>
> If you need zeroed memory always, you will likely need to write your own allocator.
>
> Security note:
>
> If you use memory (allocated or otherwise) in a privileged situation to contain security sensitive information, such as passwords, then you will need to zero the memory after use before dropping privilege, or an attack on your program in an unprivileged state may get access to the data it had access to before it dropped privilege.
>
> -- Terry
---
Mac hacker with a performance bent
http://www.linkedin.com/in/joelreymont
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden