brk's zero-fill behavior on VAXen
Arthur David Olson
"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!a...@seismo.ARPA
DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.
Guy Harris
> 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
g...@sun.com (or g...@sun.arpa)
Larry Campbell
>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%maynar...@harvisr.harvard.edu (617) 367-6846
Theodore Hope
>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: Ho...@ics.GATECH.EDU
uucp: ...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!hope
Doug Gwyn
>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 Wiegand
>In article <72...@elsie.UUCP> a...@elsie.UUCP (Arthur David Olson) writes:
>>Can system performance be improved by avoiding zero filling of the new
>>memory?
>
>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%cadi...@cu-arpa.cs.cornell.edu)
Daniel R. Levy
>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 Tilson
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!mike
Paul McJones
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
mcj...@src.dec.com
Guy Harris
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
Arthur David Olson
> > memory?
>
> Yes, a little bit, but this would be an obvious security hole.
What's clearly called for is a memory mapping feature that instructs the
hardware to randomize the data in a page once it's been abandoned. A likely
name would be "Destroy on Deallocation," or, for short, "DoD." Such a
feature would allow paranoid programs to ensure security without penalizing
other programs.
Comfy chair
Actually this idea was seriously suggested in one of the Multics papers
(if I remember correctly), a hardware line that would reset all bits
in a memory region. I surmise CPU speed has improved so much with respect
to memory speed that this is no longer a significant penalty.
Ken
Roy Smith
> 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!"