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