Re: [Projectudi-patches] CB realloc spanking patch

[Steven B. <sb...@st...>]

Ok, let me just add that I actually tested the patch with 0xDC
"Destroyed Controlblock" before changing it to 0x00 for the
patches mailing list. :-)

--Steve


On Tue, Jun 22, 2004 at 06:22:43PM +0100, James Hall wrote:
> I agree with Bela that filling with NULLs is a mediocre solution. What 
> about filling with an odd-byte pattern such that structure accessing 
> would _probably_ cause an access fault -- certainly the case on at least 
> one big-endian architecture, and also on x86 for larger than byte 
> quantities. Perhaps something along the lines of 0xdeadbeef ??
> 
> Cheers,
> 
> James
> 
> Bela Lubkin wrote:
> >Robert Lipe wrote:
> >
> >
> >>>Filling with zeros doesn't taint well enough, for two reasons:
> >>
> >>Debugging taints of any kind are an asymptote.
> >
> >
> >Agreed.  I'm just not convinced that the proposed taint actually moves
> >towards and not away from the asymptotic goal!  Filling in nulls catches
> >bad references to pointers pulled out of a freed struct (on most OSes in
> >most circumstances).  But it also _protects_ code that already checks
> >part of its work.  It gets us closer to the goal in the case of:
> >
> >  my_ptr = freed_ptr->xyz_cb;  /* we just dereferenced a freed ptr */
> >  if (my_ptr->blah)            /* we just dereferenced NULL */
> >
> >It _hides_ errors in the case of:
> >
> >  my_ptr = freed_ptr->xyz_cb;  /* we just dereferenced a freed ptr */
> >  if (!my_ptr) return;         /* and we didn't hear a peep about it */
> >  if (my_ptr->blah)            /* we never get to dereferencing NULL */
> >
> >
> >>>I don't think a byte value exists which you can assume will make bad
> >>>pointers on all possible OSes.  Is 0xFEFEFEFE a bad pointer on all x86
> >>>OSes?  Is 0xFEFEFEFEFEFEFEFE bad on all 64-bit OSes?  Some framework is
> >>
> >>That's sort of what NULL pointers are about, but when you have OSes that
> >>cater to dumb code to allow bad NULL references, life gets hard becuase
> >>you then can't differentiate between benign NULL derefs and dumb NULL
> >>derefs.   
> >
> >
> >The OS-specific details about zero pages are just a minor detail.  The
> >big problem is the hiding of generic bugs.
> >
> >
> >>>  /* Initialized in source or maybe at runtime to a pointer value
> >>>     that's guaranteed to always be bad on the target OS; 4- or 8-
> >>>     bytes depending on OS pointer size.  Preferably not just a bad
> >>
> >>We could do such a thing in the osdep.h, but doing this well would
> >>require knowing which members of the buf you're destroying are pointers
> >>and which are bitfields and which are reference counts and such.  Of
> >>course, doing this in the bowels of cb reallocation would require
> >>trawling the layout_t's and such and it just gets icky.
> >
> >
> >You don't need that much knowledge.  Yes, a bug could also be hidden if
> >it depended on a bitfield:
> >
> >  if (freed_ptr->flags & FOO_FLAG) {
> >    go wrong
> >  }
> >
> >well, that's your asymptote for you.  It could also depend on:
> >
> >  if (!(freed_ptr->flags & FOO_FLAG))
> >
> >so there's no way to reliably catch that except by actually unmapping
> >the pages pointed to by freed objects, as you say below:
> >
> >
> >>I won't veto the 80/20 solution.
> >>
> >>Personally, I'd be more tempted to "fix" the VM mappings for such OSes
> >>(at least while in kernel mode) or to flat out put cb's in a page of
> >>their own and unmap them or such than to get too nutsy with complexity
> >>in here.
> >
> >
> >That's also nutsy complex -- lots of interaction with the env.
> >
> >If you fill freed data with nonzero stuff, at least it won't be
> >protected by "is this pointer I picked up NULL?" tests.  You'll get
> >slapped when you should.
> >
> >
> >>Bela<
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> >digital self defense, top technical experts, no vendor pitches, 
> >unmatched networking opportunities. Visit www.blackhat.com
> >_______________________________________________
> >Projectudi-patches mailing list
> >Pro...@li...
> >https://lists.sourceforge.net/lists/listinfo/projectudi-patches
> 
> 
> -- 
> ------------------------------------------------------------
> James Hall			email: jam...@su...
> Sun Microsystems		phone: +44-1923-696862
> 54 Clarendon Rd,		Sun ext: x78962
> Watford,			Fax:   +44-1923-696801
> Herts WD17 1DU
> United Kingdom
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Projectudi-patches mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/projectudi-patches