[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

Jeff Morriss wrote:
> Evan Huus wrote:
> > They've been on my to-do list for a while, as emem provides them.
> >
> > However, I've never personally used emem's canaries, and I've never
> > actually heard of or seen anyone else using them. Are they actually
> > useful anymore, or has Moore's law made valgrind the better tool in
> > all situations?
>
> Well, the canaries have helped us find (and fix) a *lot* of bugs over 
> the years.  I have this vague memory of a time when most of the fuzz 
> failures complained of canary corruption but maybe that's an 
> exaggeration.  Hopefully the lack of canary corruption these days is a 
> sign of improvement. :-)
>
> I think they're still useful for the automated fuzz testing because we 
> get a fuzz failure when the fuzz-bot finds a corrupted canary.  Valgrind 
> is useful to let us humans *find* the memory corruption, but unless 
> we're at a point where the fuzz-bot can run Valgrind instead of its 
> normal testing, I don't think we should give up the canaries.
>
> > If we do believe they're still useful, now's the time to suggest cool
> > new features for them etc. Would they be used more if could be enabled
> > with an environment variable instead of a compile flag? Are the
> > mprotected pages actually useful, or are 99% of things caught by the
> > simpler canaries?
>
> There are environment variables to enable/disable the canaries: that's 
> what allows the Valgrind script to actually work. :-)

Of course as soon as I hit "Send" I realized I was thinking of something 
different: the environment variables which control how the allocations 
are done, not whether or not there are canaries.

But there are still environment variables for the canaries: in 
particular, SE canaries are off by default (because they were using a 
*lot* of memory) but we turn them on while fuzz testing.