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

[A collective reply, in order of receipt]

Thanks for the responses.

email@hidden
Dirty" RAM can contain any data, and legitimate consumers of that memory can inadvertently pass along sensitive data if the memory isn't zeroed first.

OK good argument :) I don't think that if I had the OS under my thumb, that I would punish all programs because of certain ill-conceived other programs, but I can see why one would chose to do so to protect the innocent user. The not so innocent user might like to turn this off with sysctl.

Mighty Maomoondog <email@hidden>
A compromised program could easily read other processes memory and spew out valuable information (think CC numbers, Quicken data, your diary entry about your torrid affair with Britney Spears, etc.) onto the internet.

"Clark S. Cox III" <email@hidden>

Zero filling is my bottleneck currently.

Are you sure? how did you determine this.

Using sample. The first routine to touch a page is really expensive.

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

Yes but if my system is compromised or running a trojan, then the malicious code leafing through reused RAM pages would not be my first concern. My immediate concern would be that it sends out all the data it can just grab directly off the harddisk, address book etc..


So still, I would like to chose to not have that security in trade off for speed.

As an example, if I run a big make session, I could do with out the zero filling time. I am not sayin its a bottleneck there, but it isn't helping either. If I compile 100 files, and I am running that through gcc, that means AFAIK 3 stages, let each of those use 32 MB memory or 8000 pages data, that'd be 2.4 Mpages to be zero filled, which would mean on my Cube more than a minute spent zero filling. Certainly won't break my neck, but also quite certainly (for me) superflous.

---

Ed Wynne <email@hidden>
Its been my growing impression that the fault cost (trip into the kernel, then back out)
and the page allocation cost tend to dwarf the zero-fill cost.

Would be interesting to know. From my observations (I have a slow Cube though), I see all the performance going down in the first write access to an allocated page, the vm_allocate calls do seem to be pretty quick.
I suspect that it is really the memory bandwidth that is the problem. (The zero filling also does throw away 4K of the instruction cache, so there will be an additional 4K recaching need - if I read the source correctly)


Jim Magee <email@hidden>
(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.

Aha! Is there a rule of thumb, when it is better to vm_deallocate pages than to keep them cached for reuse and msync them ? (I believe that vm_deallocate does a little defragmentation...)

Ciao
Nat!
_______________________________________________
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: 
 >zero filling pages (From: Nat! <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.