From owner-freebsd-hackers Tue Feb 16 18:18:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id C2C2211132 for ; Tue, 16 Feb 1999 18:18:39 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA26146; Tue, 16 Feb 1999 19:18:39 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd026081; Tue Feb 16 19:18:23 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA16616; Tue, 16 Feb 1999 19:18:22 -0700 (MST) From: Terry Lambert Message-Id: <199902170218.TAA16616@usr08.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Wed, 17 Feb 1999 02:18:22 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902170152.UAA00758@y.dyson.net> from "John S. Dyson" at Feb 16, 99 08:52:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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