Bug 1034894

Code contributions always welcome :-)  I suspect the printf family would be fairly painful to handle.

My understanding of the _chk thingies is that when not expanded inline by the compiler, they will call their appropriate glibc function.  ie, memcpy_chk will call memcpy if the compiler doesn't expand the memcpy_chk inline.  So there's nothing to do for them.  Is that not the case?

Note memstomp simply can't catch things which are inline expanded by the compiler.  No way around that.

(In reply to Jeff Law from comment #2)

> My understanding of the _chk thingies is that when not expanded inline by
> the compiler, they will call their appropriate glibc function.  ie,
> memcpy_chk will call memcpy if the compiler doesn't expand the memcpy_chk
> inline.  So there's nothing to do for them.  Is that not the case?

Surprisingly, no.  __memcpy_chk has an open-coded version.  If we change that, we risk uncovering further overlapping buffers, but perhaps we should make the change upstream, so that we can eventually benefit from all those memcpy optimizations.

> Note memstomp simply can't catch things which are inline expanded by the
> compiler.  No way around that.

Well, there is -ftree-loop-distribute-patterns, which could reverse that (sort of). :)

Covering sprintf probably isn't worth the trouble.  Maybe that's something where glibc could help.

Egad.  There's a wonderful set of _chk entry points.  There's a nice collection of mem* and str* functions and the wide variants of the str* functions. 


I also just realized that even if the _chk function calls the real one after passing the length check, it's probably done in a way that wouldn't allow memstomp to intercept those calls/jumps.  What a mess.

Upstream for memstomp is Will Cohen (and John Reiser).  I don't think any significant changes have been made in a couple years.  We should probably consider Fedora's repository the effective upstream repo and try to get this into F21 & RHEL 7.1.

No work has been done on this issue; there's effectively no chance it's going to show up in in this release of DTS.  Deferring for next release.

As we've discussed before the "rebase" brought in no new upstream code, just a tag.  There is a patch in rawhide to enable checking of certain str* and mem* for NULL pointers in places where a NULL pointer is invalid.  Pulling in those changes is a completely separate issue.

My gut tells me to wait on the NULL checking.

While I've got some code to do that upstream, I haven't added testsuites for that code yet and the new code hasn't had all that much testing.  It may be something we can add for 3.1 since it's a single, isolated patch.

It would also be good to do another once-over for functions we want to check for invalid NULL arguments.  Basically there's so many functions where NULL pointers aren't allowed that covering them all would be insane.  There's a *much* smaller set where the checking is actually useful.  Basically we want to check where those NULL pointers may _not_ be dereferenced by the runtime due to other arguments (such as a length).  Those are the cases where we want to add the interposition routines for checking purposes.

Realistically memstomp never turned out to be all that useful.  Investing further here isn't on the radar.