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