Date: Wed, 17 Feb 1999 02:18:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902170218.TAA16616@usr08.primenet.com> In-Reply-To: <199902170152.UAA00758@y.dyson.net> from "John S. Dyson" at Feb 16, 99 08:52:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 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. 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. 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). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199902170218.TAA16616>