There are good *performance* reasons to zero at allocation time: it eliminates memory reads (CLZ == Cache Line Zero).<br><br>In any case, uninitialized data is just not okay for any reason.<br><br><div class="gmail_quote">
On Sun, Mar 15, 2009 at 8:09 PM, Eric Rannaud <span dir="ltr"><<a href="mailto:eric.rannaud@gmail.com">eric.rannaud@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sun, Mar 15, 2009 at 10:25:52PM +0000, David-Sarah Hopwood wrote:<br>
> Eric Rannaud wrote:<br>
> > On Sun, Mar 15, 2009 at 05:35:27PM -0400, Geoffrey Irving wrote:<br>
> >> A thought that occurred to me after the discussion of array<br>
> >> initialization: allowing user access to uninitialized memory opens a<br>
> >> security hole. It would become possible to read passwords or other<br>
> >> sensitive data out of the "uninitialized" memory, which would rule out<br>
> >> the use of BitC for intraprocess access control setups. I think this<br>
> >> is more than enough to kill the idea of an uninitialized allocation<br>
> >> primitive.<br>
> ><br>
> > That's the job of the operating system. [...]<br>
><br>
> No, Geoffrey is talking about sensitive data left by the same process<br>
> (note "intraprocess"). A secure language implementation can rely on new<br>
> pages obtained from the operating system being zeroed, but it still has<br>
> to zero memory recovered by garbage collection (or explicit deallocation<br>
> if supported) before it is reused.<br>
<br>
</div>To clarify: yes it may have to be performed by the language runtime in<br>
some contexts (Singularity or those you mention), but I fail to see how<br>
this should be part of the language specification (and the runtime spec<br>
therein).<br>
<br>
Without some kind of access control framework (e.g. capabilities),<br>
disallowing uninitialized allocation is not going to go very far to<br>
prevent information leakage between parts of the application (the<br>
language cannot help you enforce this, so you're at the mercy of a<br>
variety of programming errors).<br>
<br>
This being said, it is true that zeroing on garbage collection is<br>
necessary in some contexts.<br>
<br>
I understand we all come to BitC with different interests: I want a<br>
safer and higher-level language with the performance of C (speed and<br>
memory wise), both for HPC and embedded. Others want very different<br>
things from BitC.<br>
<br>
Ultimately, Jonathan et al. will design BitC based on their own<br>
priorities, of course. But I do hope the various conflicts between the<br>
needs of the users of BitC can be dealt with configurable options, and a<br>
flexible runtime, providing various levels of guarantees.<br>
<div><div></div><div class="h5">_______________________________________________<br>
bitc-dev mailing list<br>
<a href="mailto:bitc-dev@coyotos.org">bitc-dev@coyotos.org</a><br>
<a href="http://www.coyotos.org/mailman/listinfo/bitc-dev" target="_blank">http://www.coyotos.org/mailman/listinfo/bitc-dev</a><br>
<br>
</div></div></blockquote></div><br>