Mail Archives: djgpp/2019/06/17/02:33:51
On Mon, 17 Jun 2019 02:12:26 -0400
Rod Pemberton <invalid AT lkntrgzxc DOT com> wrote:
> On Mon, 17 Jun 2019 01:48:19 -0400
> Rod Pemberton <invalid AT lkntrgzxc DOT com> wrote:
>
> > On Mon, 17 Jun 2019 01:28:32 -0400
> > "Frank Sapone (emoaddict15 AT gmail DOT com) [via djgpp AT delorie DOT com]"
> > <djgpp AT delorie DOT com> wrote:
> >
> > > On 6/17/2019 1:05 AM, Rod Pemberton wrote:
> > > > On Mon, 17 Jun 2019 02:27:18 +0200
> > > > "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]"
> > > > <djgpp AT delorie DOT com> wrote:
> >
> > > >> I ran into this issue with malloc(). It seems that, given
> > > >> enough allocations, malloc() will eventually return a pointer
> > > >> into already allocated memory.
> > > >>
> > > >> The attached program is able to reproduce this rather
> > > >> consistently, but only under cwsdpmi. It also only happens if
> > > >> the memory has previously been written to (suggesting a paging
> > > >> issue?). However the code that first led me to investigate this
> > > >> also exhibits the same problem under hdpmi. As such, I'm still
> > > >> not entirely convinced that this initial issue wasn't caused by
> > > >> my own code. I also find it hard to believe that no one else
> > > >> noticed this rather obvious problem before me. Still, the
> > > >> attached program demonstrates this clobbering issue, and I
> > > >> think this would warrant further investigation.
> > > >>
> > > >> Any insight is much appreciated.
> > > >>
> > > > First problem is trivial. The code doesn't compile with older
> > > > DJGPP v1.3. The declaration of 'i' within the for() loop
> > > > errors, but other C99 declarations only warn.
> > > >
> > > > Second problem is you don't call memset() prior to using memory,
> > > > nor free() after you're done using it. Of course, calling
> > > > memset() would prevent your method of "clobber" detection from
> > > > working. But, not calling memset() means you don't know if the
> > > > magic clobber value is: a) from you setting it within your
> > > > program, or b) from some random garbage values in memory.
> > > >
> > > > Third problem is you apparently didn't test the program without
> > > > the "p[i] = magic;" line. If you had, you would've noticed that
> > > > your program clobbers even without setting memory to magic
> > > > values. In other words, memory is filled with random values,
> > > > since it wasn't cleared by memset(). Also, some of those random
> > > > values happen to match your program's random magic value used to
> > > > detect clobbered memory.
> > > >
> > > > Fourth problem is that you can't actually confirm if memory is
> > > > being clobbered from within a C program for two reasons:
> > > > inability to distinguish a magic value from an identical random
> > > > value in memory which hasn't been cleared, and the inability in
> > > > C to allocate, clear, and free memory, prior to the re-use of
> > > > the exact same memory for a clobber test. To test this issue
> > > > properly requires a modified version of the memory allocator,
> > > > i.e., CWSDPMI in this case.
> > > >
> > > > Finally, you didn't report which version of DJGPP, or CWSDPMI,
> > > > and whether or not your code is operating in a Windows
> > > > 98/SE/ME/XP etc console. When operating in a Windows console,
> > > > CWSDPMI is not being used. The Windows DPMI host is being used.
> > > >
> > > >
> > >
> > > Good points. I was thinking some of the same things when I read
> > > this post earlier, but I am not as much of a C guru as others
> > > here. My initial thoughts were that memset was not being called
> > > and that it was a random integer for the magic value that there is
> > > a possibility of grabbing the same value.
> > >
> >
> > One thing he could do is reduce the likelihood, i.e., probability,
> > that he'll get a false positive, i.e., random value. He could check
> > for multiple magic values in a row. The more values he checks for,
> > the lower the probability will be that it's random. I'd probably
> > check for an entire block. However, even long sequences can be
> > random or perhaps stale program data. E.g., a roulette wheel could
> > in theory land one on the color red for millions of spins or more,
> > while the odds or likelihood that it lands on either black or red
> > hasn't changed. I.e., there is no absolute certainty that a
> > detected "clobber" isn't random.
> >
>
> Well, I decided to see what happens when I check for two magic values
> in a row (without setting any magic values). I'm no longer see any
> matches with random data (although there could still be).
>
> So, I also decided to check for two magic values, while also setting
> the magic values, and then dump the eight prior values in a row. I'm
> seeing eight magic values in a row ... Not good. Maybe, he found an
> issue with "clobber," but his posted test program was too simplified,
> i.e., matching random data.
>
> At this point, it's up to someone else to verify, after making needed
> changes to his code.
Oops. Never mind. The program is setting the eight prior (more)
values. I should've checked forwards. BRB.
Rod Pemberton
--
Once upon a time, many decades ago in a place far away, humble people
sought their freedom, and lost. "Ideas are bulletproof."
- Raw text -