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
