Re: What does tainting actually mean?

[Valdis . Kletnieks]

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.

Attachment: pgp00000.pgp
Description: PGP signature