Messages in this thread | | | Subject | Re: What does tainting actually mean? | From | Valdis.Kletnieks@vt ... | Date | Wed, 28 Apr 2004 12:01:13 -0400 |
| |
On Wed, 28 Apr 2004 15:18:35 +1000, Nigel Cunningham said:
> I don't know what module you're talking about, but surely there must be > something that could be done kernel-side to protect against such problems. > Reference counting or such like? I guess if it was a hardware issue, but > then again that might be an issue with too many assumptions being made > about prior state? Maybe I am being too naive :>
I once had the joy of debugging a memory overlay issue in an X.500 product, that surfaced while porting from a "working" platform (IBM's AIX/370 product) to IBM's AIX on the RS6K line.
The problem had the following characteristics:
It worked fine on AIX/370 (due to the way it's malloc() worked). It worked fine on the RS6K if a debugging malloc() was used (and I tried 3 different ones).
It only crashed using the native malloc(), and the actual overlay happened fairly early on, but the overlay's effects didn't become apparent till some 6 million (yes really) more malloc() calls allocated another 120M (yes really) on the heap. It was going *way* off the end of an allocated array, and the canaries allocated by the AIX/370 and debugging mallocs caused the stray store to hit non-critical data - but it hit a pointer used by the native malloc (actually hopping over 2 entire other structures in the process), and said botched pointer didn't surface till free() was called on that specific structure.
Isn't much you can do kernel-side to protect against that sort of stray pointer, unless you're using a tagged architecture like the late Intel i432 chipset.
[unhandled content-type:application/pgp-signature] | |