Re: no movement on Critical issues; 2.16 in Oct ?

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote:
>> Modern operating systems don't give your code any leftovers from a
>> previous run.  That would be a security violation.
>
> I'm certain that I've seen an uninitialized variable being
> 123456789 in some cases, and 0 in others.  I sincerly doubt that
> modern operating systems remember what collection of bits were in
> memory at just before the first initialization, so the security
> step would surely be simply writing 0s to that location in memory.

If the stack never previously was used to that depth.  I did not say
that you don't get leftovers from previous function calls.  And yes, you
usually get zeros for uninitialized memory.

>> And even user stack initialization below the stack pointer is not
>> stochastical.
>
> Hmm, I may be misunderstanding this sentence due to my relative
> ignorance of low-level OS stuff (I had a quite varied career as an
> undergraduate).  If you mean "the computer starts reserving pieces of
> memory for variables in different places in memory on each run", then
> my 0-theorizing above is false.

That's not what I mean, though Linux indeed nowadays has kernel
parameters for randomizing its virtual storage layout to make it harder
to developer exploits for system libraries.  If bugs pop up only
occasionally, it might be worth switching this off and see whether it
stabilizes the problem in either direction.

> But I'm pretty certain that I've seen student programs (running in
> 3-year-old cygwin on windows 2000, so perhaps not the most secure of
> environments) share unitialized variable locations across program
> runs.

Windows 2000 (not NT-based IIRC) does not usefully employ memory
protection IIRC, so likely Cygwin does not add all too much on top.

-- 
David Kastrup