Mail Archives: djgpp/2019/06/17/03:33:49
On Mon, 17 Jun 2019 02:31:44 -0400
Rod Pemberton <invalid AT lkntrgzxc DOT com> wrote:
> On Mon, 17 Jun 2019 02:14:55 -0400
> Rod Pemberton <invalid AT lkntrgzxc DOT com> wrote:
> > 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.
> >
>
> Not good.
>
> I just checked forward. Two values is still sufficient to prevent
> detecting random data on my machine (not setting any magic values).
> Setting the magic values shows the next eight values in a row to have
> the magic values once a "clobber" is detected. It looks like he may
> have found "clobbering".
>
I also tried with two different magic values. Same results.
I see the "clobber" issue with r5 and r7 of CWSDPMI. 6b of CWSPMDI
errors with SISSEGV. CWSDPR0 aborts with an error about allocating
page tables. PMODETSR completes without any "clobbers".
The program seems to make a large number (on my machine) of small
allocations around ~268M (~0x0ff5d000) before a "clobber". CWSDPR0
aborts with an error about page tables. Could CWSDPMI be running out
of page tables? ... Also, IIRC, PMODETSR doesn't use paging, and it
completes without any "clobbers". The large number of allocation might
also be why no one noticed, or maybe this was a known issue in the past
but forgotten?
BFN, (no more time for this)
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 -