[bitc-dev] nondeterminism and access control
Eric Rannaud
eric.rannaud at gmail.com
Sun Mar 15 17:49:39 EDT 2009
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. When a process requests memory,
the OS will provide "safe" memory: either pages the process was the last
owner of, or other pages that will be zeroed, exactly for the reason you
mention.
This kind of consideration doesn't belong to a language's runtime (maybe
in a system like Singularity from MS Research, but we're not talking
about that for BitC). The reason is that the OS already cares about
security (and containment between processes), and it cannot trust the
applications (and their runtime) to not look at the content of newly
allocated pages. So the OS has to clear the pages itself.
When you use BitC to program the OS itself, you will have to zero
pages explicitly. You cannot just clear any newly allocated memory: for
instance, it doesn't make a lot of sense to zero out an area reserved
for DMA.
More information about the bitc-dev
mailing list