Date: Wed, 12 Jan 2005 14:32:43 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: "Kernel" dumps. Message-ID: <Pine.NEB.3.96L.1050112142745.41530B-100000@fledge.watson.org> In-Reply-To: <20050112131950.GN795@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Jan 2005, Pawel Jakub Dawidek wrote: > We need improve our dumps, really. > > First of all they are too big, because we dump whole memory. Second of > all, they are not safe for our users. > > We should implement two things: > > - dumping only kernel pages (dump is smaller and without sensitive data > from userland processes); > - add a malloc(9) flag M_NOUMP which will prevent from dumping > pages with sensitive data (e.g. GBDE keys). > > Any VM-skilled volunteers? Pretty please... While I don't object in principle to these changes (and recognize why they would be quite beneficial), an important consideration in any touching of the debugging code is minimizing the chances that corrupt kernel data structures will prevent us from gathering debugging information effectively. If the dump code has to walk VM data structures extensively, that increases the risk that the dump will fail due to an invalid pointer dereference, especially if what's being debugged is a VM bug. We already enter a temporary mapping for each physical page during the dump process so that the pages can be dumped, I guess, so maybe this is not such a big issue. However, one of the things that has made FreeBSD a great operating system to develop on in the past has been robust and consistent debugging tools--the current tools seem a little less robust post-SMPng, largely due to relatively minor nits that need to be cleaned up, but I'd hate for them to get less reliable if that's avoidable. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050112142745.41530B-100000>