> > consumes a lot of time.
> It is apparent that you didn't understand the well-proven concept. The
> idea is that, unless actually written, the zero-filled memory doesn't have
> to exist at all! This is called "demand-zero" paging and has been used
> in VAXen forever.
True. However, either you still have to have page table entries for all
those "demand-zero" virtual pages, or every read access turns into a
page fault. This problem shrinks somewhat with the Cx6x86's variable-
sized pages and the Pentium's 4 MB (?) pages...
> Further, for security reasons, VAXen do not allow a user to read OLD data
> that might have been written by some other task at some time. Therefore,
> even if you allocate a buffer locally on the stack, the buffer is zeroed.
If the page is neither zeroed nor overwritten with something else which
I ought to have access to, sane users will scream bloody murder.
> Note that I don't advocate copying Digital's mistakes. However we can
> learn a lot about performance by understanding how these things work. One
> of the problems with "Digital security" is that if you extend a file, the
> data is written to zero before you are allowed to access that file. That
> takes a lot of CPU cycles and hurts performance.
I'd just pretend to load it in from disk and stick one of my pre-zeroed
(or zero-on-read) pages in as its "buffer". Or I'd make the kernel
enforce getting back nothing but zeroes (or failures) trying to read
past the end of a file. It doesn't need to be zeroed by hand before
any access, it just needs to look like zeroes or end up being zeroes
(minus any writes) when it comes time to write the block back to the disk...
The features you described as "VAX security" are, imho, essential as far
as their effects are concerned; we should feel free to implement them
as intelligently as possible.
Keith