Re: [cap-talk] RumpelTree++

"Jonathan S. Shapiro" <[email protected]> Sun, 27 Jul 2014 12:10:38 -0700
Newsgroups gmane.comp.lang.e.general
Message-ID <CAAP=3QPtuCiUQD9sBqE=NhJpd31tKOhCcASn09hjWTHNUvxX-Q@mail.gmail.com>
On Sat, Jul 26, 2014 at 3:11 PM, Bill Frantz <[email protected]> wrote:

> I guess I'm completely obsolete. I thought all real systems with
> any security story at all would zero pages being allocated
> across security boundaries. KeyKOS/CapROS etc. do. What systems don't?


I'm not aware of *any* mainstream operating systems that allocate non-zero
pages to malloc.

There used to be some cases in UNIX/Linux where the transfer of data in
(e.g.) a write call that copies data from user space to file buffer pages
might skip zeroing of the buffer page if and only if the entire kernel
buffer page is being overwritten. What happened if a page fault occurred in
mid-transfer and the application had registered a signal handler for
SIGSEGV in this case was never clear to me. A subsequent read() from that
buffer page would honor the transfer length limit, but if the buffer page
is mmap'd... Oh. No. If it's mmap'd then the page zero will have already
occurred before the mmap proceeded.

These days, I believe most UNIX systems strictly maintain the rule of "page
zero before allocate", though they *do* use permission and status bits to
implement just-in-time zero in the event that background zeroing logic
hasn't gotten to the frame in time. WIndows and OSX do this as well. I'm
not sure about mobile OSs.


shap

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang