From dan@dan.emsphone.com  Tue Nov 26 18:00:14 2002
Return-Path: <dan@dan.emsphone.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 912B737B401; Tue, 26 Nov 2002 18:00:14 -0800 (PST)
Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1B12143EA9; Tue, 26 Nov 2002 18:00:14 -0800 (PST)
	(envelope-from dan@dan.emsphone.com)
Received: (from dan@localhost)
	by dan.emsphone.com (8.12.6/8.12.6) id gAR20Dbk099944;
	Tue, 26 Nov 2002 20:00:13 -0600 (CST)
	(envelope-from dan)
Message-Id: <200211270200.gAR20Dbk099944@dan.emsphone.com>
Date: Tue, 26 Nov 2002 20:00:13 -0600 (CST)
From: Dan Nelson <dnelson@allantgroup.com>
Reply-To: Dan Nelson <dnelson@allantgroup.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc: phk@freebsd.org
Subject: crashdump issue with too-small dumpdev
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         45777
>Category:       kern
>Synopsis:       crashdump issue with too-small dumpdev
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 26 18:10:01 PST 2002
>Closed-Date:    Thu Mar 22 06:59:36 GMT 2007
>Last-Modified:  Thu Mar 22 06:59:36 GMT 2007
>Originator:     Dan Nelson
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
The Allant Group
>Environment:
System: FreeBSD dan.emsphone.com 5.0-CURRENT FreeBSD 5.0-CURRENT #223: Sun Nov 24 14:13:14 CST 2002 dan@dan.emsphone.com:/usr/src/sys/i386/compile/DANSMP i386


	
>Description:

I finally discovered why I have never been able to get crashdumps to
work: at some point all error-checking in the dump routines
disappeared.  I happen to have 1 GB of RAM, and 640MB of swap (old
system, and I never reformatted after adding RAM).

dumpon lets me set the dump device to my teeny 640MB swap partition,
and when it comes time to dump, dumpsys calculates

dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE;

which in my case ends up being a negative number.  The dump ends up
failing when it tries to write to a negative block number and the SCSI
drive refuses the request.  So it seems like there are three bugs here:

1 - /sbin/dumpon doesn't verify RAM size against raw device size.  This
    may be forgivable, as neither is all that easy to calculate from
    userland.

2 - ioctl(DIOCSKERNELDUMP) lets me set my dump device to something
    smaller than maxmem.

3 - dumpsys doesn't range-check its calculations.

I'm just lucky I don't have a 384MB root partition, or the first time I
pancied I would have overwritten my root :)

If at some point we are going to support sparse dumps (only dump kernel
and say, wired pages, for example), then #1 and #2 sort of go away,
since we don't know the size of the dump until we crash.  But I don't
want crash dumps leaking over to other partitions, no matter what.

>How-To-Repeat:
	

1. Run dumpon on a partition smaller than your memory size
2. Panic
3. The partition just before your dumpon partition will have crashdump
   data in it, if the panic was able to write a dump at all.

>Fix:

	


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Dan Nelson <dnelson@allantgroup.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, <phk@FreeBSD.ORG>
Subject: Re: kern/45777: crashdump issue with too-small dumpdev
Date: Wed, 27 Nov 2002 18:45:02 +1100 (EST)

 On Tue, 26 Nov 2002, Dan Nelson wrote:
 
 > >Description:
 >
 > I finally discovered why I have never been able to get crashdumps to
 > work: at some point all error-checking in the dump routines
 > disappeared.  I happen to have 1 GB of RAM, and 640MB of swap (old
 > system, and I never reformatted after adding RAM).
 
 It disappeared in rev.1.132 of kern_shutdown.c.  brian fixed the case
 of devices of size 0 in rev.1.60 of subr_disk.c.
 
 > dumpon lets me set the dump device to my teeny 640MB swap partition,
 > and when it comes time to dump, dumpsys calculates
 >
 > dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE;
 >
 > which in my case ends up being a negative number.  The dump ends up
 > failing when it tries to write to a negative block number and the SCSI
 > drive refuses the request.  So it seems like there are three bugs here:
 
 > 1 - /sbin/dumpon doesn't verify RAM size against raw device size.  This
 >     may be forgivable, as neither is all that easy to calculate from
 >     userland.
 
 It makes a syscall that can do it, but the syscall never bothered
 because the dump device (size) may change after it has been checked.
 It would just be nice for /sbin/dumpon to warn if the device is too
 small and for something to warn if the dump device size changes.  OTOH,
 I consider even the existence of /sbin/dumpon to be overengineering.
 In its current form it does nothing that the sysctl couldn't do (early
 versions of the sysctl couldn't print the device name).
 
 > 2 - ioctl(DIOCSKERNELDUMP) lets me set my dump device to something
 >     smaller than maxmem.
 >
 > 3 - dumpsys doesn't range-check its calculations.
 
 4 - dumpsys has lost even its primitive understanding of leaving space
 for metadata.
 
 > I'm just lucky I don't have a 384MB root partition, or the first time I
 > pancied I would have overwritten my root :)
 
 That would be good luck too.  The worst case is overwriting a large
 non-FreeBSD filesystem which is not owned by you.  It can happen that
 the final offset is nonnegative but
 di->mediasize - Maxmem * (off_t)PAGE_SIZE is negative.  Then a slice
 or partition other than the dump device slice is scribbled on (brian
 fixed a special case of this).  Or
 di->mediasize - Maxmem * (off_t)PAGE_SIZE may be small.  Then metadata
 (boot blocks and/or label) is scribbled on.
 
 Bruce
 
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Thu Mar 22 06:59:06 UTC 2007 
State-Changed-Why:  
The ticket mentions this problem had vanished. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=45777 
>Unformatted:
