Date: Tue, 16 Feb 1999 22:07:35 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902170307.WAA27574@y.dyson.net> In-Reply-To: <199902170218.TAA16616@usr08.primenet.com> from Terry Lambert at "Feb 17, 99 02:18:22 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said: > > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > > > > Actually, you have to support that on most practical architectures. > > [ ... ] > > > malloc and calloc are different. Memory is often recycled in the > > address space when using malloc. sbrk is a security violation if > > the pages aren't prezeroed (or defined to be something other than > > data in other processes or freed data from the kernel :-)). > > Well, the intended application doesn't care about security, so it > should be possible to turn it off. 8-). > > The thing that appalled me was what you said about BSS being zero'ed > in the kernel space using zeroed pages instead of as a result of an > explicit zeroing by the execution class loader. > That is the way that it works. Explict zeroing is wasteful because it cannot easily take advantage of background prezeroing... However, recently prezeroed pages make for efficient usage of cache. The zero queue (and all others) are designed to take advantage of recent cache usage. > > On second thought, though, are the BSS pages zeroed because they > are backed by zero-fill pages, rather than grabbed in user space > via sbrk? That's less apalling. You could conditionalize that > code. > They are backed by zero-fill pages. Processes don't do the zeroing themselves because of security reasons (in current kernels.) The execution class loaders sometimes have to do explict zeroes due to broken non-aligned binary formats. The kernel has efficient mechanisms for providing zeroed pages, but I guess that there are times that even efficiently zeroing pages isn't fast enough. > > I think the compile option he wants to add is "VM_FG_ZERO_PAGES" > or something similar, that indicates the subsystem effected and > the effect, and then "VM_DIRTY_PAGES_OK". > > In other words, I'd seperate turning off the background zeroing and > the default-mandatory nature of pages zeroed for security rather > than functional purposes. > Well, that is an application issue (how you would want to implement it from an enable/disable standpoint.) All I am saying is that implementing the details of how it works is easy -- perhaps not obvious to a non-kernel hacker though. The kind of thing being asked for requires only an addition of a simple flag to a map entry, and the appropriate modification of how fault works when that flag is set. > > Another place that would have to be conditionalized, besides the > /dev/zero and BSS issues, would be backing store for file pages > allocated on a file extend. I know a number of programs that > rely on the POSIX sideways promise that "holes contain zeros" > (it's OK to break security, but not semantics). > Those pages should be zeroed anyway in any case. In the same way that bss almost has to be pre-zeroed (for reasonable behavior of standard C programs), proper zeroing of file contents is likely necessary to keep programmers from going nutty. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902170307.WAA27574>