Re: [cap-talk] RumpelTree++

So would you say in-process zeroing of secrets after usage to protect
against malloc attacks has become totally unneeded?




On Sun, July 27, 2014 21:10, Jonathan S. Shapiro wrote:
> 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
>