On Sun, 24 Mar 2002, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Robe
> rt Watson writes:
> >A few weeks ago, I would have believed you.  Except that using -J was a
> >workaround recommended in a recent security advisory--prior to
> >recommending it, I ran it on a server of mine for a few days.  You'd be
> >surprised how many random applications keel over, and the performance
> >impact it has for some specific types of applications.
> No, I will not be surprised no matter what you tell me.  I used to keep
> save all emails I got about phkmalloc nailing bugs, now I only track
> "significant" ones. 
> But let me turn it around, what would it take for you to accept AJ in
> the developer release ?  Better diagnostics ? 

Hmm.  The argument for A is, I think, is a lot stronger than for J, since
it comes without the performance impact, and you can actually generate
useful diagnostics.  I would be fine with leaving A in the developer
snapshot. On the issue of making diagnostics more useful: sending this
debugging information to syslog might be one way.  The 'abort' already
ends up on the console and in the log:

Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on
signal 6 (core dumped)

Making that more informative might be helpful.  I.e., 

  Mar 24 12:25:39 paprika tmp: pid 52818: application error, double
  free(), aborting.
  Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on
  signal 6 (core dumped)

would probably go a long way.  This addresses the problem of "stderr lost
for some or another reason, but the kernel message remains".  On the other
hand, it does introduce some potential recursion/reentrancy issues.

I like the impact of J from the perspective of an application developer
knowingly specifically turning it on, but part of the general problem with
J is that the failure detection occurs as part of the application code,
rather than specifically in a system library that can provide improved
reporting.  For example: ckimail is a command line IMAP tool which scans a
set of IMAP mailboxes.  It contains a bug (I assume) involving use of
memory following a free().  With J turned on, it segfaults almost
immediately on start (very soon after execve() completes).  I'd like to be
able to distinguish between bugs caused by this type of improved
application debugging, and bugs generated by incorrect stack and signal
handling, etc, which have the same failure mode (Segmentation Violation,
Core Dumped).  Other than playing electric fence-like games with memory
protection and signal handlers (or heavy instrumentation in the form of
purify), it's not clear to me how catching free'd memory use maps into
specific reporting output.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to