From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 22:03:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5962816A419 for ; Fri, 25 Jan 2008 22:03:11 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 2A41813C478 for ; Fri, 25 Jan 2008 22:03:10 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1314559waf.3 for ; Fri, 25 Jan 2008 14:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OJtdjVI0uObM0V1ETtg0xhjRx4qluS3ijwDuphbqvQk=; b=JlnS6fI16+BQgbYInK5rbkFo2NzGm4XnZ+3YaXYETYP/AASnNjkB46bVZXMsaYu62soIc2Jv2hYLspDJ4od8em7Yl/vJVUo/8ceFCEWU+ITdk6MndV2R9sijPi2exTDSR6zRFiwpsr/1S5V/SSB75VbdvkYYs1Y1ivOARZeoinA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=itvzTWRTO03sXbEF7z/ajCiPiIhxh6absJmY3tQae0KDddKYl6uG78TLsWoOAUUCxgksOjD0tf1e1qiX1WRGUYjGj1qKh3rfOZzPhX19BhWO3m5g7AR5qoIwYlp+NNf0bDwmVFH+BG+C1U/aosVqp/lI2N8WjzkES1Ge/3X7svg= Received: by 10.115.95.1 with SMTP id x1mr2856942wal.94.1201297045921; Fri, 25 Jan 2008 13:37:25 -0800 (PST) Received: by 10.114.255.16 with HTTP; Fri, 25 Jan 2008 13:37:25 -0800 (PST) Message-ID: Date: Fri, 25 Jan 2008 13:37:25 -0800 From: "Kip Macy" To: "Peter Jeremy" In-Reply-To: <20080125204735.GQ53741@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080125180740.GA1646@team.vega.ru> <479A305E.3020801@samsco.org> <20080125204735.GQ53741@server.vk2pj.dyndns.org> Cc: current@freebsd.org Subject: Re: minidumps are unsafe on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 22:03:11 -0000 On Jan 25, 2008 12:47 PM, Peter Jeremy wrote: > On Fri, Jan 25, 2008 at 11:54:22AM -0700, Scott Long wrote: > >Ruslan Ermilov wrote: > >> Kernel minidumps on amd64 SMP can write beyond the bounds > >> of the configured dump device causing (as in our case) the > >> file system data following swap partition to be overwritten > >> with the dump contents. > ... > >> This only affects 7.x/8.x amd64 SMP systems configured with > >> minidump. i386 systems aren't affected. > >> > > > >Is this a case where you are manually triggering a dump on a > >system that is otherwise running fine? > > IMO, this is irrelevant. Over-writing data outside the defined > partition boundaries is unacceptable on a production system. Uhm, not really. If the caller is violating the conditions expected / required by the dump routines then it is the caller (i.e. the code path for creating dumps artificially) that needs to be fixed. > > It would be nice if there were some sanity checks to pick this up. > Somewhere down the chain, one of the lower-level write functions > should verify that each write is contained within > [dumperinfo.mediaoffset .. dumperinfo.mediaoffset+dumperinfo.mediasize) > Ideally this would be inside dumperinfo.dumper() but that function > doesn't currently get passed dumperinfo so this change is too > intrusive for 7.0. Likewise dumperinfo.dumper() is called in too > many places to reasonably add the code to the callers. Maybe a > MI wrapper function replacing each of the existing dumperinfo.dumper() > calls would be the least intrusive fix: Replace each existing > di->dumper(di->priv, va, pa, offset, len); > with > dumper_write(di, va, pa, offset, len); > and add the following in (probably) kern/kern_shutdown: > void > dumper_write(struct dumperinfo *di, void *va, vm_offset_t *pa, off_t offset, size_t length) > { > if (offset >= di->mediaoffset && > offset + size <= di->mediaoffset + di->mediasize) > di->dumper(di->priv, va, pa, offset, len); > else > printf("Attempt to write outside dumpdev boundaries ignored\n"); > } > > >that's one thing. If it's a case where you're trying to fix > >something that isn't broken, then I'm very cautious about the > >added complexity that you're proposing. > > I'd suggest that, for 7.0-RELEASE, either amd64 minidumps, or manually > triggered amd64 minidumps, needs to be disabled (or hidden behind a > "do you really want to shoot yourself in the foot" check). This can > be noted in ERRATA and fixed in 7.1. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. >