Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
/*-
|
2017-11-27 15:14:46 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
|
|
|
|
*
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
* Copyright (c) 2007 Robert N. M. Watson
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*-
|
2008-01-10 00:26:47 +00:00
|
|
|
* Kernel text-dump support: write a series of text files to the dump
|
|
|
|
* partition for later recovery, including captured DDB output, kernel
|
|
|
|
* configuration, message buffer, and panic message. This allows for a more
|
|
|
|
* compact representation of critical debugging information than traditional
|
|
|
|
* binary dumps, as well as allowing dump information to be used without
|
|
|
|
* access to kernel symbols, source code, etc.
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
*
|
|
|
|
* Storage Layout
|
|
|
|
* --------------
|
|
|
|
*
|
|
|
|
* Crash dumps are aligned to the end of the dump or swap partition in order
|
|
|
|
* to minimize the chances of swap duing fsck eating into the dump. However,
|
|
|
|
* unlike a memory dump, we don't know the size of the textdump a priori, so
|
|
|
|
* can't just write it out sequentially in order from a known starting point
|
|
|
|
* calculated with respect to the end of the partition. In order to address
|
|
|
|
* this, we actually write out the textdump in reverse block order, allowing
|
|
|
|
* us to directly align it to the end of the partition and then write out the
|
|
|
|
* dump header and trailer before and after it once done. savecore(8) must
|
|
|
|
* know to reverse the order of the blocks in order to produce a readable
|
|
|
|
* file.
|
|
|
|
*
|
2008-01-10 00:26:47 +00:00
|
|
|
* Data is written out in the ustar file format so that we can write data
|
|
|
|
* incrementally as a stream without reference to previous files.
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
*
|
|
|
|
* TODO
|
|
|
|
* ----
|
|
|
|
*
|
2016-04-29 20:53:39 +00:00
|
|
|
* - Allow subsystems to register to submit files for inclusion in the text
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
* dump in a generic way.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
|
|
#include "opt_config.h"
|
|
|
|
|
2012-11-01 04:07:08 +00:00
|
|
|
#include "opt_ddb.h"
|
|
|
|
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/conf.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/kerneldump.h>
|
|
|
|
#include <sys/msgbuf.h>
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
|
|
|
#include <ddb/ddb.h>
|
|
|
|
#include <ddb/db_lex.h>
|
|
|
|
|
|
|
|
static SYSCTL_NODE(_debug_ddb, OID_AUTO, textdump, CTLFLAG_RW, 0,
|
|
|
|
"DDB textdump options");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't touch the first SIZEOF_METADATA bytes on the dump device. This is
|
|
|
|
* to protect us from metadata and metadata from us.
|
|
|
|
*/
|
|
|
|
#define SIZEOF_METADATA (64*1024)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Data is written out as a series of files in the ustar tar format. ustar
|
|
|
|
* is a simple streamed format consiting of a series of files prefixed with
|
|
|
|
* headers, and all padded to 512-byte block boundaries, which maps
|
|
|
|
* conveniently to our requirements.
|
|
|
|
*/
|
|
|
|
struct ustar_header {
|
|
|
|
char uh_filename[100];
|
|
|
|
char uh_mode[8];
|
|
|
|
char uh_tar_owner[8];
|
|
|
|
char uh_tar_group[8];
|
|
|
|
char uh_size[12];
|
|
|
|
char uh_mtime[12];
|
|
|
|
char uh_sum[8];
|
|
|
|
char uh_type;
|
|
|
|
char uh_linkfile[100];
|
|
|
|
char uh_ustar[6];
|
|
|
|
char uh_version[2];
|
|
|
|
char uh_owner[32];
|
|
|
|
char uh_group[32];
|
|
|
|
char uh_major[8];
|
|
|
|
char uh_minor[8];
|
|
|
|
char uh_filenameprefix[155];
|
|
|
|
char uh_zeropad[12];
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Various size assertions -- pretty much everything must be one block in
|
|
|
|
* size.
|
|
|
|
*/
|
|
|
|
CTASSERT(sizeof(struct kerneldumpheader) == TEXTDUMP_BLOCKSIZE);
|
|
|
|
CTASSERT(sizeof(struct ustar_header) == TEXTDUMP_BLOCKSIZE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is a textdump scheduled? If so, the shutdown code will invoke our dumpsys
|
|
|
|
* routine instead of the machine-dependent kernel dump routine.
|
|
|
|
*/
|
2012-11-01 04:07:08 +00:00
|
|
|
#ifdef TEXTDUMP_PREFERRED
|
|
|
|
int textdump_pending = 1;
|
|
|
|
#else
|
|
|
|
int textdump_pending = 0;
|
|
|
|
#endif
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, pending, CTLFLAG_RW,
|
|
|
|
&textdump_pending, 0,
|
|
|
|
"Perform textdump instead of regular kernel dump.");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Various constants for tar headers and contents.
|
|
|
|
*/
|
|
|
|
#define TAR_USER "root"
|
|
|
|
#define TAR_GROUP "wheel"
|
|
|
|
#define TAR_UID "0"
|
|
|
|
#define TAR_GID "0"
|
|
|
|
#define TAR_MODE "0600"
|
|
|
|
#define TAR_USTAR "ustar"
|
|
|
|
|
|
|
|
#define TAR_CONFIG_FILENAME "config.txt" /* Kernel configuration. */
|
|
|
|
#define TAR_MSGBUF_FILENAME "msgbuf.txt" /* Kernel messsage buffer. */
|
|
|
|
#define TAR_PANIC_FILENAME "panic.txt" /* Panic message. */
|
|
|
|
#define TAR_VERSION_FILENAME "version.txt" /* Kernel version. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Configure which files will be dumped.
|
|
|
|
*/
|
|
|
|
#ifdef INCLUDE_CONFIG_FILE
|
|
|
|
static int textdump_do_config = 1;
|
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, do_config, CTLFLAG_RW,
|
|
|
|
&textdump_do_config, 0, "Dump kernel configuration in textdump");
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static int textdump_do_ddb = 1;
|
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, do_ddb, CTLFLAG_RW,
|
|
|
|
&textdump_do_ddb, 0, "Dump DDB captured output in textdump");
|
|
|
|
|
|
|
|
static int textdump_do_msgbuf = 1;
|
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, do_msgbuf, CTLFLAG_RW,
|
|
|
|
&textdump_do_msgbuf, 0, "Dump kernel message buffer in textdump");
|
|
|
|
|
|
|
|
static int textdump_do_panic = 1;
|
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, do_panic, CTLFLAG_RW,
|
|
|
|
&textdump_do_panic, 0, "Dump kernel panic message in textdump");
|
|
|
|
|
|
|
|
static int textdump_do_version = 1;
|
|
|
|
SYSCTL_INT(_debug_ddb_textdump, OID_AUTO, do_version, CTLFLAG_RW,
|
|
|
|
&textdump_do_version, 0, "Dump kernel version string in textdump");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* State related to incremental writing of blocks to disk.
|
|
|
|
*/
|
|
|
|
static off_t textdump_offset; /* Offset of next sequential write. */
|
|
|
|
static int textdump_error; /* Carried write error, if any. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Statically allocate space to prepare block-sized headers and data.
|
|
|
|
*/
|
|
|
|
char textdump_block_buffer[TEXTDUMP_BLOCKSIZE];
|
|
|
|
static struct kerneldumpheader kdh;
|
|
|
|
|
|
|
|
/*
|
2008-01-10 00:26:47 +00:00
|
|
|
* Calculate and fill in the checksum for a ustar header.
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ustar_checksum(struct ustar_header *uhp)
|
|
|
|
{
|
|
|
|
u_int sum;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < sizeof(uhp->uh_sum); i++)
|
|
|
|
uhp->uh_sum[i] = ' ';
|
|
|
|
sum = 0;
|
|
|
|
for (i = 0; i < sizeof(*uhp); i++)
|
|
|
|
sum += ((u_char *)uhp)[i];
|
|
|
|
snprintf(uhp->uh_sum, sizeof(uhp->uh_sum), "%6o", sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Each file in the tarball has a block-sized header with its name and other,
|
|
|
|
* largely hard-coded, properties.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
textdump_mkustar(char *block_buffer, const char *filename, u_int size)
|
|
|
|
{
|
|
|
|
struct ustar_header *uhp;
|
|
|
|
|
2012-11-01 04:07:08 +00:00
|
|
|
#ifdef TEXTDUMP_VERBOSE
|
|
|
|
if (textdump_error == 0)
|
|
|
|
printf("textdump: creating '%s'.\n", filename);
|
|
|
|
#endif
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
uhp = (struct ustar_header *)block_buffer;
|
|
|
|
bzero(uhp, sizeof(*uhp));
|
|
|
|
strlcpy(uhp->uh_filename, filename, sizeof(uhp->uh_filename));
|
|
|
|
strlcpy(uhp->uh_mode, TAR_MODE, sizeof(uhp->uh_mode));
|
|
|
|
snprintf(uhp->uh_size, sizeof(uhp->uh_size), "%o", size);
|
|
|
|
strlcpy(uhp->uh_tar_owner, TAR_UID, sizeof(uhp->uh_tar_owner));
|
|
|
|
strlcpy(uhp->uh_tar_group, TAR_GID, sizeof(uhp->uh_tar_group));
|
|
|
|
strlcpy(uhp->uh_owner, TAR_USER, sizeof(uhp->uh_owner));
|
|
|
|
strlcpy(uhp->uh_group, TAR_GROUP, sizeof(uhp->uh_group));
|
|
|
|
snprintf(uhp->uh_mtime, sizeof(uhp->uh_mtime), "%lo",
|
|
|
|
(unsigned long)time_second);
|
|
|
|
uhp->uh_type = 0;
|
|
|
|
strlcpy(uhp->uh_ustar, TAR_USTAR, sizeof(uhp->uh_ustar));
|
|
|
|
ustar_checksum(uhp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* textdump_writeblock() writes TEXTDUMP_BLOCKSIZE-sized blocks of data to
|
|
|
|
* the space between di->mediaoffset and di->mediaoffset + di->mediasize. It
|
|
|
|
* accepts an offset relative to di->mediaoffset. If we're carrying any
|
|
|
|
* error from previous I/O, return that error and don't continue to try to
|
|
|
|
* write. Most writers ignore the error and forge ahead on the basis that
|
|
|
|
* there's not much you can do.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
textdump_writeblock(struct dumperinfo *di, off_t offset, char *buffer)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (textdump_error)
|
|
|
|
return (textdump_error);
|
|
|
|
if (offset + TEXTDUMP_BLOCKSIZE > di->mediasize)
|
|
|
|
return (EIO);
|
|
|
|
if (offset < SIZEOF_METADATA)
|
|
|
|
return (ENOSPC);
|
2008-01-31 16:22:14 +00:00
|
|
|
textdump_error = dump_write(di, buffer, 0, offset + di->mediaoffset,
|
|
|
|
TEXTDUMP_BLOCKSIZE);
|
2012-11-01 04:07:08 +00:00
|
|
|
if (textdump_error)
|
|
|
|
printf("textdump_writeblock: offset %jd, error %d\n", (intmax_t)offset,
|
|
|
|
textdump_error);
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
return (textdump_error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Interfaces to save and restore the dump offset, so that printers can go
|
|
|
|
* back to rewrite a header if required, while avoiding their knowing about
|
|
|
|
* the global layout of the blocks.
|
2008-01-10 00:26:47 +00:00
|
|
|
*
|
|
|
|
* If we ever want to support writing textdumps to tape or other
|
|
|
|
* stream-oriented target, we'll need to remove this.
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
textdump_saveoff(off_t *offsetp)
|
|
|
|
{
|
|
|
|
|
|
|
|
*offsetp = textdump_offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
textdump_restoreoff(off_t offset)
|
|
|
|
{
|
|
|
|
|
|
|
|
textdump_offset = offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Interface to write the "next block" relative to the current offset; since
|
|
|
|
* we write backwards from the end of the partition, we subtract, but there's
|
|
|
|
* no reason for the caller to know this.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
textdump_writenextblock(struct dumperinfo *di, char *buffer)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = textdump_writeblock(di, textdump_offset, buffer);
|
|
|
|
textdump_offset -= TEXTDUMP_BLOCKSIZE;
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef INCLUDE_CONFIG_FILE
|
|
|
|
extern char kernconfstring[];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dump kernel configuration.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
textdump_dump_config(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
u_int count, fullblocks, len;
|
|
|
|
|
|
|
|
len = strlen(kernconfstring);
|
|
|
|
textdump_mkustar(textdump_block_buffer, TAR_CONFIG_FILENAME, len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write out all full blocks directly from the string, and handle any
|
|
|
|
* left-over bits by copying it to out to the local buffer and
|
|
|
|
* zero-padding it.
|
|
|
|
*/
|
|
|
|
fullblocks = len / TEXTDUMP_BLOCKSIZE;
|
|
|
|
for (count = 0; count < fullblocks; count++)
|
|
|
|
(void)textdump_writenextblock(di, kernconfstring + count *
|
|
|
|
TEXTDUMP_BLOCKSIZE);
|
|
|
|
if (len % TEXTDUMP_BLOCKSIZE != 0) {
|
|
|
|
bzero(textdump_block_buffer, TEXTDUMP_BLOCKSIZE);
|
|
|
|
bcopy(kernconfstring + count * TEXTDUMP_BLOCKSIZE,
|
|
|
|
textdump_block_buffer, len % TEXTDUMP_BLOCKSIZE);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif /* INCLUDE_CONFIG_FILE */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dump kernel message buffer.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
textdump_dump_msgbuf(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
off_t end_offset, tarhdr_offset;
|
|
|
|
u_int i, len, offset, seq, total_len;
|
|
|
|
char buf[16];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write out a dummy tar header to advance the offset; we'll rewrite
|
|
|
|
* it later once we know the true size.
|
|
|
|
*/
|
|
|
|
textdump_saveoff(&tarhdr_offset);
|
|
|
|
textdump_mkustar(textdump_block_buffer, TAR_MSGBUF_FILENAME, 0);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy out the data in small chunks, but don't copy nuls that may be
|
|
|
|
* present if the message buffer has not yet completely filled at
|
|
|
|
* least once.
|
|
|
|
*/
|
|
|
|
total_len = 0;
|
|
|
|
offset = 0;
|
2014-10-11 20:25:19 +00:00
|
|
|
msgbuf_peekbytes(msgbufp, NULL, 0, &seq);
|
|
|
|
while ((len = msgbuf_peekbytes(msgbufp, buf, sizeof(buf), &seq)) > 0) {
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
if (buf[i] == '\0')
|
|
|
|
continue;
|
|
|
|
textdump_block_buffer[offset] = buf[i];
|
|
|
|
offset++;
|
|
|
|
if (offset != sizeof(textdump_block_buffer))
|
|
|
|
continue;
|
|
|
|
(void)textdump_writenextblock(di,
|
|
|
|
textdump_block_buffer);
|
|
|
|
total_len += offset;
|
|
|
|
offset = 0;
|
|
|
|
}
|
2014-10-11 20:25:19 +00:00
|
|
|
}
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
total_len += offset; /* Without the zero-padding. */
|
|
|
|
if (offset != 0) {
|
|
|
|
bzero(textdump_block_buffer + offset,
|
|
|
|
sizeof(textdump_block_buffer) - offset);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rewrite tar header to reflect how much was actually written.
|
|
|
|
*/
|
|
|
|
textdump_saveoff(&end_offset);
|
|
|
|
textdump_restoreoff(tarhdr_offset);
|
|
|
|
textdump_mkustar(textdump_block_buffer, TAR_MSGBUF_FILENAME,
|
|
|
|
total_len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
textdump_restoreoff(end_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
textdump_dump_panic(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
u_int len;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write out tar header -- we store up to one block of panic message.
|
|
|
|
*/
|
|
|
|
len = min(strlen(panicstr), TEXTDUMP_BLOCKSIZE);
|
|
|
|
textdump_mkustar(textdump_block_buffer, TAR_PANIC_FILENAME, len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Zero-pad the panic string and write out block.
|
|
|
|
*/
|
|
|
|
bzero(textdump_block_buffer, sizeof(textdump_block_buffer));
|
|
|
|
bcopy(panicstr, textdump_block_buffer, len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
textdump_dump_version(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
u_int len;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write out tar header -- at most one block of version information.
|
|
|
|
*/
|
|
|
|
len = min(strlen(version), TEXTDUMP_BLOCKSIZE);
|
|
|
|
textdump_mkustar(textdump_block_buffer, TAR_VERSION_FILENAME, len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Zero pad the version string and write out block.
|
|
|
|
*/
|
|
|
|
bzero(textdump_block_buffer, sizeof(textdump_block_buffer));
|
|
|
|
bcopy(version, textdump_block_buffer, len);
|
|
|
|
(void)textdump_writenextblock(di, textdump_block_buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Commit text dump to disk.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
textdump_dumpsys(struct dumperinfo *di)
|
|
|
|
{
|
Add support for encrypted kernel crash dumps.
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
|
|
|
struct kerneldumpcrypto *kdc;
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
off_t dumplen, trailer_offset;
|
|
|
|
|
|
|
|
if (di->blocksize != TEXTDUMP_BLOCKSIZE) {
|
|
|
|
printf("Dump partition block size (%ju) not textdump "
|
|
|
|
"block size (%ju)", (uintmax_t)di->blocksize,
|
|
|
|
(uintmax_t)TEXTDUMP_BLOCKSIZE);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't know a priori how large the dump will be, but we do know
|
|
|
|
* that we need to reserve space for metadata and that we need two
|
|
|
|
* dump headers. Also leave room for one ustar header and one block
|
|
|
|
* of data.
|
|
|
|
*/
|
|
|
|
if (di->mediasize < SIZEOF_METADATA + 2 * sizeof(kdh)) {
|
2012-11-01 04:07:08 +00:00
|
|
|
printf("Insufficient space on dump partition for minimal textdump.\n");
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
textdump_error = 0;
|
|
|
|
|
Add support for encrypted kernel crash dumps.
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
|
|
|
/*
|
|
|
|
* Disable EKCD because we don't provide encrypted textdumps.
|
|
|
|
*/
|
2018-01-08 21:27:41 +00:00
|
|
|
kdc = di->kdcrypto;
|
|
|
|
di->kdcrypto = NULL;
|
Add support for encrypted kernel crash dumps.
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
|
|
|
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
/*
|
|
|
|
* Position the start of the dump so that we'll write the kernel dump
|
|
|
|
* trailer immediately before the end of the partition, and then work
|
|
|
|
* our way back. We will rewrite this header later to reflect the
|
|
|
|
* true size if things go well.
|
|
|
|
*/
|
|
|
|
textdump_offset = di->mediasize - sizeof(kdh);
|
|
|
|
textdump_saveoff(&trailer_offset);
|
2017-08-18 04:04:09 +00:00
|
|
|
dump_init_header(di, &kdh, TEXTDUMPMAGIC, KERNELDUMP_TEXT_VERSION, 0);
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
(void)textdump_writenextblock(di, (char *)&kdh);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write a series of files in ustar format.
|
|
|
|
*/
|
|
|
|
if (textdump_do_ddb)
|
|
|
|
db_capture_dump(di);
|
|
|
|
#ifdef INCLUDE_CONFIG_FILE
|
|
|
|
if (textdump_do_config)
|
|
|
|
textdump_dump_config(di);
|
|
|
|
#endif
|
|
|
|
if (textdump_do_msgbuf)
|
|
|
|
textdump_dump_msgbuf(di);
|
2020-01-12 06:07:54 +00:00
|
|
|
if (textdump_do_panic && KERNEL_PANICKED())
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
textdump_dump_panic(di);
|
|
|
|
if (textdump_do_version)
|
|
|
|
textdump_dump_version(di);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that we know the true size, we can write out the header, then
|
|
|
|
* seek back to the end and rewrite the trailer with the correct
|
|
|
|
* size.
|
|
|
|
*/
|
|
|
|
dumplen = trailer_offset - (textdump_offset + TEXTDUMP_BLOCKSIZE);
|
2017-08-18 04:04:09 +00:00
|
|
|
dump_init_header(di, &kdh, TEXTDUMPMAGIC, KERNELDUMP_TEXT_VERSION,
|
|
|
|
dumplen);
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
(void)textdump_writenextblock(di, (char *)&kdh);
|
|
|
|
textdump_restoreoff(trailer_offset);
|
|
|
|
(void)textdump_writenextblock(di, (char *)&kdh);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Terminate the dump, report any errors, and clear the pending flag.
|
|
|
|
*/
|
|
|
|
if (textdump_error == 0)
|
2008-01-31 16:22:14 +00:00
|
|
|
(void)dump_write(di, NULL, 0, 0, 0);
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
if (textdump_error == ENOSPC)
|
2012-11-01 04:07:08 +00:00
|
|
|
printf("Textdump: Insufficient space on dump partition\n");
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
else if (textdump_error != 0)
|
2012-11-01 04:07:08 +00:00
|
|
|
printf("Textdump: Error %d writing dump\n", textdump_error);
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
else
|
|
|
|
printf("Textdump complete.\n");
|
|
|
|
textdump_pending = 0;
|
Add support for encrypted kernel crash dumps.
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Restore EKCD status.
|
|
|
|
*/
|
2018-01-08 21:27:41 +00:00
|
|
|
di->kdcrypto = kdc;
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-
|
|
|
|
* DDB(4) command to manage textdumps:
|
|
|
|
*
|
|
|
|
* textdump set - request a textdump
|
|
|
|
* textdump status - print DDB output textdump status
|
|
|
|
* textdump unset - clear textdump request
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
db_textdump_usage(void)
|
|
|
|
{
|
|
|
|
|
2012-11-01 04:07:08 +00:00
|
|
|
db_printf("textdump [unset|set|status|dump]\n");
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2015-05-21 15:16:18 +00:00
|
|
|
db_textdump_cmd(db_expr_t addr, bool have_addr, db_expr_t count, char *modif)
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
{
|
|
|
|
int t;
|
|
|
|
|
|
|
|
t = db_read_token();
|
|
|
|
if (t != tIDENT) {
|
|
|
|
db_textdump_usage();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (db_read_token() != tEOL) {
|
|
|
|
db_textdump_usage();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (strcmp(db_tok_string, "set") == 0) {
|
|
|
|
textdump_pending = 1;
|
|
|
|
db_printf("textdump set\n");
|
|
|
|
} else if (strcmp(db_tok_string, "status") == 0) {
|
|
|
|
if (textdump_pending)
|
|
|
|
db_printf("textdump is set\n");
|
|
|
|
else
|
|
|
|
db_printf("textdump is not set\n");
|
|
|
|
} else if (strcmp(db_tok_string, "unset") == 0) {
|
|
|
|
textdump_pending = 0;
|
|
|
|
db_printf("textdump unset\n");
|
2012-11-01 04:07:08 +00:00
|
|
|
} else if (strcmp(db_tok_string, "dump") == 0) {
|
|
|
|
textdump_pending = 1;
|
2015-05-18 22:27:46 +00:00
|
|
|
doadump(true);
|
2012-11-01 04:07:08 +00:00
|
|
|
} else {
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
db_textdump_usage();
|
2012-11-01 04:07:08 +00:00
|
|
|
}
|
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
2007-12-26 11:32:33 +00:00
|
|
|
}
|