At 13:12 26-8-2011, JMGross wrote: >----- Ursprüngliche Nachricht ----- >Von: Radu Rendec >Gesendet am: 25 Aug 2011 23:28:02 > > > I have only one question, though. Suppose you have a function that > > allocates let's say 40 bytes on the stack. An example could be declaring > > "char foo[40]" as a local variable. Let's say R1/SP is only a few bytes > > above the stack "bottom" before entering this function. When you enter > > the function, the guard code that is placed immediately before the stack > > space is now located somewhere in the middle of the stack space reserved > > for the "foo" variable. If the function only touches the first few bytes > > of "foo", it may "corrupt" data but still keep your guard codes intact. > > Then the thread switching code won't be able to detect this. Could this > > be possible or did I just misunderstand the procedure you're describing? > >You're right, this might happen. >If the local array is still on the stack, the task switch code will detect >that the SP is out-of-bounds and act as if the guard code were >overwritten. (In my implementation, it will not detect which other >thread might have been affected, if at all) >Of course this is not 100% secure. For that I had to calculate a CRC >for the stack of the thread I'm leaving. This would detect the >violation when I reactivate the other thread whose stack has been >clobbered. But I think that's too much overhead.
I've been reading this thread for a while and it makes me wonder if there is some kind of tool which can analyze the code and determine the stack usage? I think this may be a safer route than to depend on a real-time stack check. The big question is: what do you do when the stack overflows? Just resetting the MCU is probably not an option so you'll have to add extra code to handle such an 'exception'. That does not seem very trivial to me. Nico Coesel ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
