ado@elsie.UUCP (Arthur David Olson) (11/03/86)
In section 2 of the UNIX Programmer's Manual, the description of the "brk" and "sbrk" calls note only that they change the system's notion of the lowest location not used by the program. If the result of the call is to expand the address space of the process, there's no promise about the contents of the newly-available address space. Yet on our VAX (and on yours, too, if you have one) the newly-available space is always zero filled. Can system performance be improved by avoiding zero filling of the new memory? -- UNIX is a registered trademark of AT&T. -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.
guy@sun.uucp (Guy Harris) (11/03/86)
> In section 2 of the UNIX Programmer's Manual, the description of the "brk" > and "sbrk" calls note only that they change the system's notion of the > lowest location not used by the program. If the result of the call is to > expand the address space of the process, there's no promise about the > contents of the newly-available address space. There is such a promise in the System V page for "brk"/"sbrk"; it promises that the newly-available space will be zero-filled. > Can system performance be improved by avoiding zero filling of the new > memory? Perhaps, although I suspect not by much. The same could be said for the zero-filling of newly-allocated blocks of files. System *security* is definitely improved by *not* avoiding this zero-filling; the data you get from this may be somewhat random, but I wouldn't rely on that guaranteeing that nobody can extract useful information from it. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
campbell@maynard.UUCP (Larry Campbell) (11/03/86)
In article <7208@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >In section 2 of the UNIX Programmer's Manual, the description of the "brk" and >"sbrk" calls note only that they change the system's notion of the lowest >location not used by the program. If the result of the call is to expand the >address space of the process, there's no promise about the contents of the >newly-available address space. Yet on our VAX (and on yours, too, if you >have one) the newly-available space is always zero filled. > >Can system performance be improved by avoiding zero filling of the new >memory? Yes, a little bit, but this would be an obvious security hole. -- Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc. UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109 ARPA: campbell%maynard.uucp@harvisr.harvard.edu (617) 367-6846
hope@gatech.EDU (Theodore Hope) (11/03/86)
In article <7208@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >If the result of the call is to expand the >address space of the process, there's no promise about the contents of the >newly-available address space. Yet on our VAX (and on yours, too, if you >have one) the newly-available space is always zero filled. Clearly, for security reasons, you would want the kernel to zero-fill new memory allocated to a user. As for the quote "no promise about the contents... yet it's always zero-filled," it could be that after brk'ing and sbrk'ing a few times you might have data that you wrote there earlier (assuming that you didn't really "give" the page(s) back to the system.) Then again, I'm probably wrong about this. >Can system performance be improved by avoiding zero filling of the new >memory? It can be assumed that on many architectures (such as the Vax) the process of zero-filling a block of memory can be done in one or a few instructions. -- Theodore Hope School of Information & Computer Science, Georgia Tech, Atlanta GA 30332 CSNet: Hope @ gatech ARPA: Hope@ics.GATECH.EDU uucp: ...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!hope
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/03/86)
In article <7208@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >Can system performance be improved by avoiding zero filling of the new >memory? It seems likely that zero-filling is primarily for system security, to prevent one process from snooping on pieces left over from another.
garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (11/04/86)
In a recent article hope@gatech.UUCP (Theodore Hope) wrote: >In article <7208@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >>Can system performance be improved by avoiding zero filling of the new >>memory? > >It can be assumed that on many architectures (such as the Vax) the process >of zero-filling a block of memory can be done in one or a few instructions. "One or a few" is not a meaningful criterion. The Vax's MOVC5 instruction is indeed a single instruction - but it runs at just about the same speed as an equivalent sequence of CLRL (reg)+ instructions. garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
levy@ttrdc.UUCP (Daniel R. Levy) (11/04/86)
In article <7208@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes: >In section 2 of the UNIX Programmer's Manual, the description of the "brk" and >"sbrk" calls note only that they change the system's notion of the lowest >location not used by the program. If the result of the call is to expand the >address space of the process, there's no promise about the contents of the >newly-available address space. Yet on our VAX (and on yours, too, if you >have one) the newly-available space is always zero filled. > >Can system performance be improved by avoiding zero filling of the new >memory? Possibly, but it would also create a security hole where one user could examine random hunks of memory left behind by other users' processes. Zeroing is the quickest way to destroy this data. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
mike@hcr.UUCP (Mike Tilson) (11/05/86)
Several people have mentioned that it is important to clear memory
newly allocated to a process, for security reasons (since otherwise
a program could continually allocate memory in the hope of finding
interesting or secret data left over from previous processes.)
I'd like to point out that there is another very good reason to
set newly allocated memory to a fixed value: buggy programs are much
less likely to exhibit non-deterministic behavior, which makes it
much easier to fix problems. If newly allocated memory were initialized
with random values, then tracking down wild pointers, etc., would be much
harder.
/Michael Tilson, HCR, {utzoo,decvax,...}!hcr!mikemcjones@jumbo.DEC.COM (Paul McJones) (11/05/86)
--------- Arthur Olson notes that in section 2 of the UNIX Programmer's Manual, there is no guarantee that memory newly allocated by brk/sbrk is zeroed; someone else notes that System V does have such a guarantee. I ran across the following in section II of Ken Thompson's paper "UNIX Implementation" (Bell System Technical Journal, Vol. 57, No. 6, Part 2, pp. 1931-1946): "The contents of newly allocated primary memory is initialized to zero." I believe many library routines and applications have come to depend on this (perhaps by accident) and would fail if it was changed. Paul McJones DEC Systems Research Center, Palo Alto decwrl!mcjones mcjones@src.dec.com
guy@sun.uucp (Guy Harris) (11/05/86)
> "One or a few" is not a meaningful criterion. I'll agree with that, but... > The Vax's MOVC5 instruction is indeed a single instruction - but it runs > at just about the same speed as an equivalent sequence of CLRL (reg)+ > instructions. Oh, really? *Which* VAX's MOVC5 instruction? I tried this on an 11/750, and got: % cat bzeroes.s .globl _bzerow1 .align 2 _bzerow1: .word 0 movl 4(ap),r3 movc5 $0,(r3),$0,8(ap),(r3) # conventional MOVC5 ret .globl _bzerow2 .align 2 _bzerow2: .word 0 movl 4(ap),r3 movl 8(ap),r2 1: clrl (r3)+ # SOBGTR loop of CLRL sobgtr r2,1b # NOTE - "bzerow1" takes a byte ret # count, this one takes a longword # count .globl _bzerow3 .align 2 _bzerow3: .word 0 movl 4(ap),r3 clrl (r3)+ # a total of 1024 CLRLs ... clrl (r3)+ ret I built three programs, each of which just calls a byte-clearer 1024 times. The first program calls "bzerow1" with a count of 4096 (bytes); "time" gives 1.1u 0.0s 0:01 89% 5+11k 0+1io 2pf+0w The second calls "bzerow2" with a count of 1024 (longwords); "time" gives 3.6u 0.0s 0:03 95% 1+11k 0+0io 1pf+0w The third calls "bzerow3", which always clears 1024 longwords (the count is irrelevant); "time" gives 2.1u 0.0s 0:02 91% 5+11k 0+0io 1pf+0w -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
roy@phri.UUCP (Roy Smith) (11/08/86)
In article <2447@hcr.UUCP> mike@hcr.UUCP (Mike Tilson) writes: > I'd like to point out that there is another very good reason to > set newly allocated memory to a fixed value: buggy programs are much > less likely to exhibit non-deterministic behavior, which makes it > much easier to fix problems. As a straight-forward extension to that idea, there is a very good reason to make that fixed value 0. On most machines (I hope that doesn't create of flood of "not on my machine it isn't" postings) the value 0 is an illegal op code, often HALT. It is also often an illegal pointer, which will generate some sort of memory fault when dereferenced. The upshot is that if new memory (initialized to 0 by the system, but not initialized by your program) is used, you increase the chances of your program stopping quickly. Sort of a poor man's tagged memory. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell unix without deoxyribonucleic!"