Re: CompactCheckpointerRequestQueue versus pad bytes

On 16.07.2012 18:24, Robert Haas wrote:
> On Sun, Jul 15, 2012 at 5:36 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could fairly cheaply dodge the problem with padding after ForkNumber
>> if we were to zero out the whole request array at shmem initialization,
>> so that any such pad bytes are guaranteed zero. However, padding in
>> RelFileNodeBackend would be more annoying to deal with, and at least
>> in the current instantiation of those structs it's probably impossible
>> anyway. Should we document those structs as required to not contain
>> any padding, or do what's needful in checkpointer.c to not depend on
>> there not being padding?
>
> I would expect that every method we could devise for allocating a
> shared memory segment would produce all-zero bytes. There was a time
> long ago when the OS would simply hand over previously-freed pages
> with their existing contents, but I believe that was recognized as a
> security problems more than 20 years ago - maybe 30 - and I can't
> believe there is any OS we care about supporting that fails to zero
> pages before handing them out.

I wouldn't rely on that, though. I wouldn't be surprised if there was
some debugging flag or similar that initialized all pages to random
values or 0xdeadbeef or something, before handing them out to the
application. We could easily zero all shared memory on allocation
ourselves, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com