Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: zero filling pages

On Wednesday, July 23, 2003, at 10:52 AM, Steve Sisak wrote:
At 0:07 +1000 7/24/03, Wade Tregaskis wrote:
A single process on your machine is exploited, and is now running malicious code. Without zero-filled pages, this process could just repeatedly call vm_allocate and examine the unallocated pages on your system. It could then, search for recognizable patterns in the pages (credit card numbers, addresses, social security numbers, etc.).

I wonder if perhaps vm_allocate could be modified so that it tries to return memory last used by the same process, and thus not needing to be zero-filled?

That would make a lot of sense -- for each task, keep a LIFO of free pages -- this also eliminates the round-trip to the kernel for vm_allocate if the request can be satisfied with previously freed pages.

(Specifying a LIFO here because (1) a LIFO can be implemented atomically on a PPC w/o a kernel round trip and (2) recently used pages are more likely to be the the processor cache)

You also probably want a mechanism where the kernel can scavenge free pages from processes if it runs out which doesn't have to be too fancy because normally free pages will be returned when a process quits.

This is called malloc(). ;-)

You couldn't do the caching things you suggest with vm_allocate() and vm_deallocate() because of semantic guarantees around address spaces, etc... made by those calls. I guess you could argue that the kernel could go ahead and deallocate the address space but keep the [now available] physical pages in a per address space pool instead of a global one. The problem with that is the flexible sharing of individual objects and ranges of objects within an address space. A page frame that came from one [non-shared] object in an address can not freely be inserted into a different object (or even a different range of the same object) without fear of exposing potentially private data to others sharing that new object). Once you narrow down the list of places where these frames could be reused safely without zero'ing, it would be more expensive than it is worth.

Seriously, what you really seem to want is a way to override the existing malloc's save and reuse vs. free policy decisions. And that can be accomplished by creating your own malloc zone with the desired behavior. About the only thing that can't be done is to have the kernel reach up and request pages out of the pool. But your can get pretty close to that. Your malloc zone would be free to inform the kernel that certain pages are no longer in active use - so the kernel can make them ripe for first stealing and doesn't have to page them out and back in (they can re-zero fill only if its stolen in the meantime) via msync(MS_KILLPAGES or MS_DEACTIVATE) calls. All this without the overhead of releasing and re-acquiring the address space for the pages to sit in.

--Jim
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: zero filling pages (From: Wade Tregaskis <email@hidden>)
 >Re: zero filling pages (From: Steve Sisak <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.