[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Corruption of high TPA



On Fri, 2009-06-12 at 11:14 +0200, Vincent Rivière wrote:
> Petr Stehlik a écrit :
> > I thought it was the same story - copying more bytes from the original
> > stack than necessary thus reading from memory the process does not own.
> > Luckily it was easy to fix EmuTOS.
> 
> Yes, we are confused ;-)
> 
> You are right, the problem is the same in the FreeMiNT trap #1 handler 
> as it was in the EmuTOS one. The OS reads too much data from the stack. 
> Thus it crashes when the address space after the stack is not readable.
> 
> But the reason why the "memory" after the stack is not readable is 
> different in the 2 scenarios.
> In EmuTOS, it crashes because there is nothing valid after the stack, it 
> is the end of the FastRAM.
> In FreeMiNT with memory protection, it crashes because the memory after 
> the stack is made unreadable by the MMU.
> 
> 2 different scenarios, but the same kind of bug in the trap handler.
> 
> > Sorry but this sounds like the 64 bytes adjustment is still not enough
> > and the program keeps crashing on FreeMiNT? But if it was crashing you
> > couldn't read the numbers.... I am confused :)
> 
> If I initialize the stack to the end of the TPA minus 64 bytes, it does 
> not crash anymore. By doing this, we ensure that if some buggy os reads 
> too much data from the stack, it will stay in the process TPA area, so 
> it will not crash.
> By looking quickly at the FreeMiNT sources, we can see that on trap #1 
> it always reads 36 bytes from the stack. EmuTOS was reading only 2 or 4 
> additional bytes, I don't remember.
> 
> So if in the MiNTLib startup code we keep 64 unused bytes at the top of 
> the stack inside the TPA area, it will probably be enough as a 
> workaround for any buggy OS.
> 
> Adding a workaround in the MiNTLib is good, but fixing FreeMiNT like 
> EmuTOS would be even better !

Sure. We're going to need to fix MiNTlib anwyay for buggy kernels. So
please go ahead with this Vincent.

I'll take a look at FreeMiNT on my next pass.

Alan.