1996-08-19 02:19:23 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 1986, 1988, 1991, 1993
|
|
|
|
* The Regents of the University of California. All rights reserved.
|
|
|
|
* (c) UNIX System Laboratories, Inc.
|
|
|
|
* All or some portions of this file are derived from material licensed
|
|
|
|
* to the University of California by American Telephone and Telegraph
|
|
|
|
* Co. or Unix System Laboratories, Inc. and are reproduced herein with
|
|
|
|
* the permission of UNIX System Laboratories, Inc.
|
|
|
|
*
|
|
|
|
* 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.
|
2016-09-15 13:16:20 +00:00
|
|
|
* 3. Neither the name of the University nor the names of its contributors
|
1996-08-19 02:19:23 +00:00
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
|
|
|
|
*
|
|
|
|
* @(#)kern_shutdown.c 8.3 (Berkeley) 1/21/94
|
|
|
|
*/
|
|
|
|
|
2003-06-11 00:56:59 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$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
|
|
|
#include "opt_ddb.h"
|
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
|
|
|
#include "opt_ekcd.h"
|
2004-07-10 21:36:01 +00:00
|
|
|
#include "opt_kdb.h"
|
1997-08-31 23:08:38 +00:00
|
|
|
#include "opt_panic.h"
|
2004-09-02 18:59:15 +00:00
|
|
|
#include "opt_sched.h"
|
2011-04-28 16:02:05 +00:00
|
|
|
#include "opt_watchdog.h"
|
1996-08-19 02:19:23 +00:00
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/systm.h>
|
2000-05-05 09:59:14 +00:00
|
|
|
#include <sys/bio.h>
|
1997-11-18 15:16:43 +00:00
|
|
|
#include <sys/buf.h>
|
2001-06-25 18:30:42 +00:00
|
|
|
#include <sys/conf.h>
|
|
|
|
#include <sys/cons.h>
|
|
|
|
#include <sys/eventhandler.h>
|
2015-09-18 17:32:22 +00:00
|
|
|
#include <sys/filedesc.h>
|
2009-05-29 21:27:12 +00:00
|
|
|
#include <sys/jail.h>
|
2004-07-10 21:36:01 +00:00
|
|
|
#include <sys/kdb.h>
|
1996-08-19 02:19:23 +00:00
|
|
|
#include <sys/kernel.h>
|
2008-10-01 22:08:53 +00:00
|
|
|
#include <sys/kerneldump.h>
|
2000-01-07 08:36:44 +00:00
|
|
|
#include <sys/kthread.h>
|
2012-12-07 08:25:08 +00:00
|
|
|
#include <sys/ktr.h>
|
2002-01-21 01:16:11 +00:00
|
|
|
#include <sys/malloc.h>
|
1997-01-16 15:58:32 +00:00
|
|
|
#include <sys/mount.h>
|
2006-11-06 13:42:10 +00:00
|
|
|
#include <sys/priv.h>
|
2001-06-25 18:30:42 +00:00
|
|
|
#include <sys/proc.h>
|
|
|
|
#include <sys/reboot.h>
|
|
|
|
#include <sys/resourcevar.h>
|
2013-03-09 02:32:23 +00:00
|
|
|
#include <sys/rwlock.h>
|
2004-11-05 18:29:10 +00:00
|
|
|
#include <sys/sched.h>
|
2010-04-19 23:27:54 +00:00
|
|
|
#include <sys/smp.h>
|
1996-08-19 02:19:23 +00:00
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/sysproto.h>
|
2011-09-08 12:56:26 +00:00
|
|
|
#include <sys/vnode.h>
|
2011-04-28 16:02:05 +00:00
|
|
|
#include <sys/watchdog.h>
|
1996-08-19 02:19:23 +00:00
|
|
|
|
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
|
|
|
#include <crypto/rijndael/rijndael-api-fst.h>
|
|
|
|
#include <crypto/sha2/sha256.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 <ddb/ddb.h>
|
|
|
|
|
2003-08-16 16:57:57 +00:00
|
|
|
#include <machine/cpu.h>
|
2015-01-07 01:01:39 +00:00
|
|
|
#include <machine/dump.h>
|
2002-04-08 06:59:13 +00:00
|
|
|
#include <machine/pcb.h>
|
2002-03-07 04:43:51 +00:00
|
|
|
#include <machine/smp.h>
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2006-10-22 11:52:19 +00:00
|
|
|
#include <security/mac/mac_framework.h>
|
|
|
|
|
2006-04-10 10:03:41 +00:00
|
|
|
#include <vm/vm.h>
|
|
|
|
#include <vm/vm_object.h>
|
|
|
|
#include <vm/vm_page.h>
|
|
|
|
#include <vm/vm_pager.h>
|
|
|
|
#include <vm/swap_pager.h>
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
#include <sys/signalvar.h>
|
|
|
|
|
2016-04-15 17:45:12 +00:00
|
|
|
static MALLOC_DEFINE(M_DUMPER, "dumper", "dumper block buffer");
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
#ifndef PANIC_REBOOT_WAIT_TIME
|
|
|
|
#define PANIC_REBOOT_WAIT_TIME 15 /* default to 15 seconds */
|
|
|
|
#endif
|
2013-12-05 03:01:41 +00:00
|
|
|
static int panic_reboot_wait_time = PANIC_REBOOT_WAIT_TIME;
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, panic_reboot_wait_time, CTLFLAG_RWTUN,
|
2013-12-03 21:35:25 +00:00
|
|
|
&panic_reboot_wait_time, 0,
|
|
|
|
"Seconds to wait before rebooting after a panic");
|
1996-08-19 02:19:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that stdarg.h and the ANSI style va_start macro is used for both
|
|
|
|
* ANSI and traditional C compilers.
|
|
|
|
*/
|
|
|
|
#include <machine/stdarg.h>
|
|
|
|
|
2004-07-10 21:36:01 +00:00
|
|
|
#ifdef KDB
|
|
|
|
#ifdef KDB_UNATTENDED
|
Improved DDB_UNATTENDED behaviour. From the submitter:
There's something that's been bugging me for a while, so I decided to fix it.
FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least
in my opinion. The behavior change is such that:
1. Nothing changes when debugger_on_panic != 0.
2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the
machine will reboot. Also, if a trap occurs, the machine will
panic and reboot, unlike how it broke to DDB before. HOWEVER,
a trap inside DDB will not cause a panic, allowing full use
of DDB without having to worry about the machine being stuck
at a DDB prompt if something goes wrong during the day.
Patches for this behavior follow my signature, and it would
be a boon to anyone (like me) who uses DDB_UNATTENDED, but
actually wants the machine to panic on a trap (otherwise,
what's the use, if the machine causes a fatal trap rather than
a true panic, of debugger_on_panic?). The changes cause no
adverse behavior, but do involve two symbols becoming global
Submitted by: Brian Feldman <green@unixhelp.org>
1998-12-28 23:03:00 +00:00
|
|
|
int debugger_on_panic = 0;
|
1996-08-19 02:19:23 +00:00
|
|
|
#else
|
Improved DDB_UNATTENDED behaviour. From the submitter:
There's something that's been bugging me for a while, so I decided to fix it.
FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least
in my opinion. The behavior change is such that:
1. Nothing changes when debugger_on_panic != 0.
2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the
machine will reboot. Also, if a trap occurs, the machine will
panic and reboot, unlike how it broke to DDB before. HOWEVER,
a trap inside DDB will not cause a panic, allowing full use
of DDB without having to worry about the machine being stuck
at a DDB prompt if something goes wrong during the day.
Patches for this behavior follow my signature, and it would
be a boon to anyone (like me) who uses DDB_UNATTENDED, but
actually wants the machine to panic on a trap (otherwise,
what's the use, if the machine causes a fatal trap rather than
a true panic, of debugger_on_panic?). The changes cause no
adverse behavior, but do involve two symbols becoming global
Submitted by: Brian Feldman <green@unixhelp.org>
1998-12-28 23:03:00 +00:00
|
|
|
int debugger_on_panic = 1;
|
1996-08-19 02:19:23 +00:00
|
|
|
#endif
|
2011-12-13 17:59:16 +00:00
|
|
|
SYSCTL_INT(_debug, OID_AUTO, debugger_on_panic,
|
2014-06-28 03:56:17 +00:00
|
|
|
CTLFLAG_RWTUN | CTLFLAG_SECURE,
|
2011-12-14 02:31:32 +00:00
|
|
|
&debugger_on_panic, 0, "Run debugger on kernel panic");
|
2002-09-19 18:49:46 +00:00
|
|
|
|
2004-07-10 21:36:01 +00:00
|
|
|
#ifdef KDB_TRACE
|
2010-10-01 09:34:41 +00:00
|
|
|
static int trace_on_panic = 1;
|
2002-09-19 18:49:46 +00:00
|
|
|
#else
|
2010-10-01 09:34:41 +00:00
|
|
|
static int trace_on_panic = 0;
|
2002-09-19 18:49:46 +00:00
|
|
|
#endif
|
2011-12-13 17:59:16 +00:00
|
|
|
SYSCTL_INT(_debug, OID_AUTO, trace_on_panic,
|
2014-06-28 03:56:17 +00:00
|
|
|
CTLFLAG_RWTUN | CTLFLAG_SECURE,
|
2011-12-14 02:31:32 +00:00
|
|
|
&trace_on_panic, 0, "Print stack trace on kernel panic");
|
2004-07-10 21:36:01 +00:00
|
|
|
#endif /* KDB */
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2010-10-01 09:34:41 +00:00
|
|
|
static int sync_on_panic = 0;
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_kern, OID_AUTO, sync_on_panic, CTLFLAG_RWTUN,
|
2001-10-19 23:32:03 +00:00
|
|
|
&sync_on_panic, 0, "Do a sync before rebooting from a panic");
|
|
|
|
|
2011-11-07 15:43:11 +00:00
|
|
|
static SYSCTL_NODE(_kern, OID_AUTO, shutdown, CTLFLAG_RW, 0,
|
|
|
|
"Shutdown environment");
|
1999-01-30 19:28:30 +00:00
|
|
|
|
2011-09-08 12:56:26 +00:00
|
|
|
#ifndef DIAGNOSTIC
|
|
|
|
static int show_busybufs;
|
|
|
|
#else
|
|
|
|
static int show_busybufs = 1;
|
|
|
|
#endif
|
|
|
|
SYSCTL_INT(_kern_shutdown, OID_AUTO, show_busybufs, CTLFLAG_RW,
|
|
|
|
&show_busybufs, 0, "");
|
|
|
|
|
2015-10-01 10:52:26 +00:00
|
|
|
int suspend_blocked = 0;
|
|
|
|
SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW,
|
|
|
|
&suspend_blocked, 0, "Block suspend due to a pending shutdown");
|
|
|
|
|
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
|
|
|
#ifdef EKCD
|
|
|
|
FEATURE(ekcd, "Encrypted kernel crash dumps support");
|
|
|
|
|
|
|
|
MALLOC_DEFINE(M_EKCD, "ekcd", "Encrypted kernel crash dumps data");
|
|
|
|
|
|
|
|
struct kerneldumpcrypto {
|
|
|
|
uint8_t kdc_encryption;
|
|
|
|
uint8_t kdc_iv[KERNELDUMP_IV_MAX_SIZE];
|
|
|
|
keyInstance kdc_ki;
|
|
|
|
cipherInstance kdc_ci;
|
|
|
|
off_t kdc_nextoffset;
|
|
|
|
uint32_t kdc_dumpkeysize;
|
|
|
|
struct kerneldumpkey kdc_dumpkey[];
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
/*
|
|
|
|
* Variable panicstr contains argument to first call to panic; used as flag
|
|
|
|
* to indicate that the kernel has already called panic.
|
|
|
|
*/
|
|
|
|
const char *panicstr;
|
|
|
|
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
int dumping; /* system is dumping */
|
2006-02-06 10:12:00 +00:00
|
|
|
int rebooting; /* system is rebooting */
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
static struct dumperinfo dumper; /* our selected dumper */
|
2004-07-10 21:36:01 +00:00
|
|
|
|
|
|
|
/* Context information for dump-debuggers. */
|
|
|
|
static struct pcb dumppcb; /* Registers. */
|
2012-05-22 07:23:41 +00:00
|
|
|
lwpid_t dumptid; /* Thread ID. */
|
2000-10-13 21:49:19 +00:00
|
|
|
|
2015-09-18 17:32:22 +00:00
|
|
|
static struct cdevsw reroot_cdevsw = {
|
|
|
|
.d_version = D_VERSION,
|
|
|
|
.d_name = "reroot",
|
|
|
|
};
|
|
|
|
|
2000-09-03 06:44:53 +00:00
|
|
|
static void poweroff_wait(void *, int);
|
|
|
|
static void shutdown_halt(void *junk, int howto);
|
|
|
|
static void shutdown_panic(void *junk, int howto);
|
|
|
|
static void shutdown_reset(void *junk, int howto);
|
2015-09-18 17:32:22 +00:00
|
|
|
static int kern_reroot(void);
|
1999-08-21 06:24:40 +00:00
|
|
|
|
|
|
|
/* register various local shutdown events */
|
2003-02-14 12:44:48 +00:00
|
|
|
static void
|
1999-08-21 06:24:40 +00:00
|
|
|
shutdown_conf(void *unused)
|
|
|
|
{
|
2003-02-14 12:44:48 +00:00
|
|
|
|
|
|
|
EVENTHANDLER_REGISTER(shutdown_final, poweroff_wait, NULL,
|
2010-10-24 16:31:57 +00:00
|
|
|
SHUTDOWN_PRI_FIRST);
|
2003-02-14 12:44:48 +00:00
|
|
|
EVENTHANDLER_REGISTER(shutdown_final, shutdown_halt, NULL,
|
|
|
|
SHUTDOWN_PRI_LAST + 100);
|
|
|
|
EVENTHANDLER_REGISTER(shutdown_final, shutdown_panic, NULL,
|
|
|
|
SHUTDOWN_PRI_LAST + 100);
|
|
|
|
EVENTHANDLER_REGISTER(shutdown_final, shutdown_reset, NULL,
|
|
|
|
SHUTDOWN_PRI_LAST + 200);
|
1999-08-21 06:24:40 +00:00
|
|
|
}
|
1999-07-17 20:47:52 +00:00
|
|
|
|
2008-03-16 10:58:09 +00:00
|
|
|
SYSINIT(shutdown_conf, SI_SUB_INTRINSIC, SI_ORDER_ANY, shutdown_conf, NULL);
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2015-09-18 17:32:22 +00:00
|
|
|
/*
|
|
|
|
* The only reason this exists is to create the /dev/reroot/ directory,
|
|
|
|
* used by reroot code in init(8) as a mountpoint for tmpfs.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
reroot_conf(void *unused)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
struct cdev *cdev;
|
|
|
|
|
|
|
|
error = make_dev_p(MAKEDEV_CHECKNAME | MAKEDEV_WAITOK, &cdev,
|
|
|
|
&reroot_cdevsw, NULL, UID_ROOT, GID_WHEEL, 0600, "reroot/reroot");
|
|
|
|
if (error != 0) {
|
|
|
|
printf("%s: failed to create device node, error %d",
|
|
|
|
__func__, error);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SYSINIT(reroot_conf, SI_SUB_DEVFS, SI_ORDER_ANY, reroot_conf, NULL);
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
/*
|
2007-03-04 22:36:48 +00:00
|
|
|
* The system call that results in a reboot.
|
1996-08-19 02:19:23 +00:00
|
|
|
*/
|
2001-09-01 19:04:37 +00:00
|
|
|
/* ARGSUSED */
|
1996-08-19 02:19:23 +00:00
|
|
|
int
|
2011-09-16 13:58:51 +00:00
|
|
|
sys_reboot(struct thread *td, struct reboot_args *uap)
|
1996-08-19 02:19:23 +00:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2002-10-27 07:03:29 +00:00
|
|
|
error = 0;
|
|
|
|
#ifdef MAC
|
2007-10-24 19:04:04 +00:00
|
|
|
error = mac_system_check_reboot(td->td_ucred, uap->opt);
|
2002-10-27 07:03:29 +00:00
|
|
|
#endif
|
|
|
|
if (error == 0)
|
2006-11-06 13:42:10 +00:00
|
|
|
error = priv_check(td, PRIV_REBOOT);
|
2002-10-27 07:03:29 +00:00
|
|
|
if (error == 0) {
|
2015-09-18 17:32:22 +00:00
|
|
|
if (uap->opt & RB_REROOT) {
|
|
|
|
error = kern_reroot();
|
|
|
|
} else {
|
|
|
|
mtx_lock(&Giant);
|
|
|
|
kern_reboot(uap->opt);
|
|
|
|
mtx_unlock(&Giant);
|
|
|
|
}
|
2002-10-27 07:03:29 +00:00
|
|
|
}
|
2001-09-01 19:04:37 +00:00
|
|
|
return (error);
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called by events that want to shut down.. e.g <CTL><ALT><DEL> on a PC
|
|
|
|
*/
|
|
|
|
void
|
2000-08-31 00:08:50 +00:00
|
|
|
shutdown_nice(int howto)
|
1996-08-19 02:19:23 +00:00
|
|
|
{
|
2003-02-14 12:44:48 +00:00
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
if (initproc != NULL) {
|
2014-04-07 21:11:29 +00:00
|
|
|
/* Send a signal to init(8) and have it shutdown the world. */
|
2001-03-07 02:50:09 +00:00
|
|
|
PROC_LOCK(initproc);
|
2014-04-07 21:11:29 +00:00
|
|
|
if (howto & RB_POWEROFF)
|
|
|
|
kern_psignal(initproc, SIGUSR2);
|
|
|
|
else if (howto & RB_HALT)
|
|
|
|
kern_psignal(initproc, SIGUSR1);
|
|
|
|
else
|
|
|
|
kern_psignal(initproc, SIGINT);
|
2001-03-07 02:50:09 +00:00
|
|
|
PROC_UNLOCK(initproc);
|
1996-08-19 02:19:23 +00:00
|
|
|
} else {
|
2014-04-07 21:11:29 +00:00
|
|
|
/* No init(8) running, so simply reboot. */
|
2014-04-07 21:18:12 +00:00
|
|
|
kern_reboot(howto | RB_NOSYNC);
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-12-06 22:35:51 +00:00
|
|
|
static void
|
2000-09-03 06:44:53 +00:00
|
|
|
print_uptime(void)
|
1999-12-06 22:35:51 +00:00
|
|
|
{
|
|
|
|
int f;
|
|
|
|
struct timespec ts;
|
|
|
|
|
|
|
|
getnanouptime(&ts);
|
|
|
|
printf("Uptime: ");
|
|
|
|
f = 0;
|
|
|
|
if (ts.tv_sec >= 86400) {
|
2000-09-11 23:55:10 +00:00
|
|
|
printf("%ldd", (long)ts.tv_sec / 86400);
|
1999-12-06 22:35:51 +00:00
|
|
|
ts.tv_sec %= 86400;
|
|
|
|
f = 1;
|
|
|
|
}
|
|
|
|
if (f || ts.tv_sec >= 3600) {
|
2000-09-11 23:55:10 +00:00
|
|
|
printf("%ldh", (long)ts.tv_sec / 3600);
|
1999-12-06 22:35:51 +00:00
|
|
|
ts.tv_sec %= 3600;
|
|
|
|
f = 1;
|
|
|
|
}
|
|
|
|
if (f || ts.tv_sec >= 60) {
|
2000-09-11 23:55:10 +00:00
|
|
|
printf("%ldm", (long)ts.tv_sec / 60);
|
1999-12-06 22:35:51 +00:00
|
|
|
ts.tv_sec %= 60;
|
|
|
|
f = 1;
|
|
|
|
}
|
2000-09-11 23:55:10 +00:00
|
|
|
printf("%lds\n", (long)ts.tv_sec);
|
1999-12-06 22:35:51 +00:00
|
|
|
}
|
|
|
|
|
2011-06-07 01:28:12 +00:00
|
|
|
int
|
|
|
|
doadump(boolean_t textdump)
|
2002-04-08 06:59:13 +00:00
|
|
|
{
|
2011-06-07 01:28:12 +00:00
|
|
|
boolean_t coredump;
|
2014-07-25 23:52:53 +00:00
|
|
|
int error;
|
2003-02-14 12:44:48 +00:00
|
|
|
|
2014-07-25 23:52:53 +00:00
|
|
|
error = 0;
|
2011-06-07 01:28:12 +00:00
|
|
|
if (dumping)
|
|
|
|
return (EBUSY);
|
|
|
|
if (dumper.dumper == NULL)
|
|
|
|
return (ENXIO);
|
2004-07-19 18:03:02 +00:00
|
|
|
|
2002-04-08 06:59:13 +00:00
|
|
|
savectx(&dumppcb);
|
2004-07-10 21:36:01 +00:00
|
|
|
dumptid = curthread->td_tid;
|
2002-04-08 06:59:13 +00:00
|
|
|
dumping++;
|
2011-06-07 01:28:12 +00:00
|
|
|
|
|
|
|
coredump = TRUE;
|
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
|
|
|
#ifdef DDB
|
2011-06-07 01:28:12 +00:00
|
|
|
if (textdump && textdump_pending) {
|
|
|
|
coredump = FALSE;
|
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_dumpsys(&dumper);
|
2011-06-07 01:28:12 +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
|
|
|
#endif
|
2011-06-07 01:28:12 +00:00
|
|
|
if (coredump)
|
2014-07-25 23:52:53 +00:00
|
|
|
error = dumpsys(&dumper);
|
2011-06-07 01:28:12 +00:00
|
|
|
|
2008-03-04 07:39:31 +00:00
|
|
|
dumping--;
|
2014-07-25 23:52:53 +00:00
|
|
|
return (error);
|
2002-04-08 06:59:13 +00:00
|
|
|
}
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
/*
|
2004-11-07 06:58:45 +00:00
|
|
|
* Shutdown the system cleanly to prepare for reboot, halt, or power off.
|
1996-08-19 02:19:23 +00:00
|
|
|
*/
|
2010-10-18 04:30:27 +00:00
|
|
|
void
|
|
|
|
kern_reboot(int howto)
|
1996-08-19 02:19:23 +00:00
|
|
|
{
|
2015-07-29 02:26:57 +00:00
|
|
|
static int once = 0;
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2004-11-08 04:52:26 +00:00
|
|
|
#if defined(SMP)
|
2004-11-07 06:58:45 +00:00
|
|
|
/*
|
|
|
|
* Bind us to CPU 0 so that all shutdown code runs there. Some
|
|
|
|
* systems don't shutdown properly (i.e., ACPI power off) if we
|
|
|
|
* run on another processor.
|
|
|
|
*/
|
panic: add a switch and infrastructure for stopping other CPUs in SMP case
Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.
Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state
Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.
This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.
The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.
PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)
2011-12-11 21:02:01 +00:00
|
|
|
if (!SCHEDULER_STOPPED()) {
|
|
|
|
thread_lock(curthread);
|
|
|
|
sched_bind(curthread, 0);
|
|
|
|
thread_unlock(curthread);
|
|
|
|
KASSERT(PCPU_GET(cpuid) == 0, ("boot: not running on cpu 0"));
|
|
|
|
}
|
2004-11-05 18:29:10 +00:00
|
|
|
#endif
|
2006-02-06 10:12:00 +00:00
|
|
|
/* We're in the process of rebooting. */
|
|
|
|
rebooting = 1;
|
2004-11-05 18:29:10 +00:00
|
|
|
|
2001-08-21 23:29:40 +00:00
|
|
|
/* We are out of the debugger now. */
|
2004-07-10 21:36:01 +00:00
|
|
|
kdb_active = 0;
|
2001-08-21 23:29:40 +00:00
|
|
|
|
1997-08-09 01:25:54 +00:00
|
|
|
/*
|
|
|
|
* Do any callouts that should be done BEFORE syncing the filesystems.
|
|
|
|
*/
|
1999-08-21 06:24:40 +00:00
|
|
|
EVENTHANDLER_INVOKE(shutdown_pre_sync, howto);
|
1997-08-09 01:25:54 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now sync filesystems
|
|
|
|
*/
|
2015-07-29 02:26:57 +00:00
|
|
|
if (!cold && (howto & RB_NOSYNC) == 0 && once == 0) {
|
|
|
|
once = 1;
|
|
|
|
bufshutdown(show_busybufs);
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
1997-08-09 01:25:54 +00:00
|
|
|
|
1999-12-06 22:35:51 +00:00
|
|
|
print_uptime();
|
|
|
|
|
2011-12-17 15:11:22 +00:00
|
|
|
cngrab();
|
|
|
|
|
1997-08-09 01:25:54 +00:00
|
|
|
/*
|
|
|
|
* Ok, now do things that assume all filesystem activity has
|
|
|
|
* been completed.
|
|
|
|
*/
|
1999-08-21 06:24:40 +00:00
|
|
|
EVENTHANDLER_INVOKE(shutdown_post_sync, howto);
|
2004-11-07 06:58:45 +00:00
|
|
|
|
2004-07-19 18:03:02 +00:00
|
|
|
if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold && !dumping)
|
2011-06-07 01:28:12 +00:00
|
|
|
doadump(TRUE);
|
1998-09-15 08:49:52 +00:00
|
|
|
|
|
|
|
/* Now that we're going to really halt the system... */
|
1999-08-21 06:24:40 +00:00
|
|
|
EVENTHANDLER_INVOKE(shutdown_final, howto);
|
|
|
|
|
|
|
|
for(;;) ; /* safety against shutdown_reset not working */
|
|
|
|
/* NOTREACHED */
|
|
|
|
}
|
1998-09-15 08:49:52 +00:00
|
|
|
|
2015-09-18 17:32:22 +00:00
|
|
|
/*
|
|
|
|
* The system call that results in changing the rootfs.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
kern_reroot(void)
|
|
|
|
{
|
|
|
|
struct vnode *oldrootvnode, *vp;
|
|
|
|
struct mount *mp, *devmp;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (curproc != initproc)
|
|
|
|
return (EPERM);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark the filesystem containing currently-running executable
|
|
|
|
* (the temporary copy of init(8)) busy.
|
|
|
|
*/
|
|
|
|
vp = curproc->p_textvp;
|
|
|
|
error = vn_lock(vp, LK_SHARED);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
mp = vp->v_mount;
|
|
|
|
error = vfs_busy(mp, MBF_NOWAIT);
|
|
|
|
if (error != 0) {
|
|
|
|
vfs_ref(mp);
|
|
|
|
VOP_UNLOCK(vp, 0);
|
|
|
|
error = vfs_busy(mp, 0);
|
|
|
|
vn_lock(vp, LK_SHARED | LK_RETRY);
|
|
|
|
vfs_rel(mp);
|
|
|
|
if (error != 0) {
|
|
|
|
VOP_UNLOCK(vp, 0);
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
if (vp->v_iflag & VI_DOOMED) {
|
|
|
|
VOP_UNLOCK(vp, 0);
|
|
|
|
vfs_unbusy(mp);
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
VOP_UNLOCK(vp, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove the filesystem containing currently-running executable
|
|
|
|
* from the mount list, to prevent it from being unmounted
|
|
|
|
* by vfs_unmountall(), and to avoid confusing vfs_mountroot().
|
|
|
|
*
|
|
|
|
* Also preserve /dev - forcibly unmounting it could cause driver
|
|
|
|
* reinitialization.
|
|
|
|
*/
|
|
|
|
|
|
|
|
vfs_ref(rootdevmp);
|
|
|
|
devmp = rootdevmp;
|
|
|
|
rootdevmp = NULL;
|
|
|
|
|
|
|
|
mtx_lock(&mountlist_mtx);
|
|
|
|
TAILQ_REMOVE(&mountlist, mp, mnt_list);
|
|
|
|
TAILQ_REMOVE(&mountlist, devmp, mnt_list);
|
|
|
|
mtx_unlock(&mountlist_mtx);
|
|
|
|
|
|
|
|
oldrootvnode = rootvnode;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unmount everything except for the two filesystems preserved above.
|
|
|
|
*/
|
|
|
|
vfs_unmountall();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add /dev back; vfs_mountroot() will move it into its new place.
|
|
|
|
*/
|
|
|
|
mtx_lock(&mountlist_mtx);
|
|
|
|
TAILQ_INSERT_HEAD(&mountlist, devmp, mnt_list);
|
|
|
|
mtx_unlock(&mountlist_mtx);
|
|
|
|
rootdevmp = devmp;
|
|
|
|
vfs_rel(rootdevmp);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mount the new rootfs.
|
|
|
|
*/
|
|
|
|
vfs_mountroot();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update all references to the old rootvnode.
|
|
|
|
*/
|
|
|
|
mountcheckdirs(oldrootvnode, rootvnode);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add the temporary filesystem back and unbusy it.
|
|
|
|
*/
|
|
|
|
mtx_lock(&mountlist_mtx);
|
|
|
|
TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list);
|
|
|
|
mtx_unlock(&mountlist_mtx);
|
|
|
|
vfs_unbusy(mp);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
1999-08-21 06:24:40 +00:00
|
|
|
/*
|
|
|
|
* If the shutdown was a clean halt, behave accordingly.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
shutdown_halt(void *junk, int howto)
|
|
|
|
{
|
2003-02-14 12:44:48 +00:00
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
if (howto & RB_HALT) {
|
|
|
|
printf("\n");
|
|
|
|
printf("The operating system has halted.\n");
|
|
|
|
printf("Please press any key to reboot.\n\n");
|
1996-10-31 00:57:28 +00:00
|
|
|
switch (cngetc()) {
|
|
|
|
case -1: /* No console, just die */
|
|
|
|
cpu_halt();
|
|
|
|
/* NOTREACHED */
|
|
|
|
default:
|
1998-09-15 08:49:52 +00:00
|
|
|
howto &= ~RB_HALT;
|
1996-10-31 00:57:28 +00:00
|
|
|
break;
|
|
|
|
}
|
1999-08-21 06:24:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if the system paniced, pause and then reboot
|
|
|
|
* according to the specified delay.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
shutdown_panic(void *junk, int howto)
|
|
|
|
{
|
|
|
|
int loop;
|
1998-09-15 08:49:52 +00:00
|
|
|
|
1999-08-21 06:24:40 +00:00
|
|
|
if (howto & RB_DUMP) {
|
2013-12-03 21:35:25 +00:00
|
|
|
if (panic_reboot_wait_time != 0) {
|
|
|
|
if (panic_reboot_wait_time != -1) {
|
1998-09-15 08:49:52 +00:00
|
|
|
printf("Automatic reboot in %d seconds - "
|
|
|
|
"press a key on the console to abort\n",
|
2013-12-03 21:35:25 +00:00
|
|
|
panic_reboot_wait_time);
|
|
|
|
for (loop = panic_reboot_wait_time * 10;
|
1998-09-15 08:49:52 +00:00
|
|
|
loop > 0; --loop) {
|
|
|
|
DELAY(1000 * 100); /* 1/10th second */
|
|
|
|
/* Did user type a key? */
|
|
|
|
if (cncheckc() != -1)
|
|
|
|
break;
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
1998-09-15 08:49:52 +00:00
|
|
|
if (!loop)
|
1999-08-21 06:24:40 +00:00
|
|
|
return;
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
1998-09-15 08:49:52 +00:00
|
|
|
} else { /* zero time specified - reboot NOW */
|
1999-08-21 06:24:40 +00:00
|
|
|
return;
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
2002-01-18 22:45:29 +00:00
|
|
|
printf("--> Press a key on the console to reboot,\n");
|
|
|
|
printf("--> or switch off the system now.\n");
|
1998-09-15 08:49:52 +00:00
|
|
|
cngetc();
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
1999-08-21 06:24:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Everything done, now reset
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
shutdown_reset(void *junk, int howto)
|
|
|
|
{
|
2003-02-14 12:44:48 +00:00
|
|
|
|
2010-04-19 23:27:54 +00:00
|
|
|
printf("Rebooting...\n");
|
|
|
|
DELAY(1000000); /* wait 1 sec for printf's to complete and be read */
|
|
|
|
|
2009-08-13 17:09:45 +00:00
|
|
|
/*
|
2010-04-19 23:27:54 +00:00
|
|
|
* Acquiring smp_ipi_mtx here has a double effect:
|
|
|
|
* - it disables interrupts avoiding CPU0 preemption
|
|
|
|
* by fast handlers (thus deadlocking against other CPUs)
|
|
|
|
* - it avoids deadlocks against smp_rendezvous() or, more
|
|
|
|
* generally, threads busy-waiting, with this spinlock held,
|
|
|
|
* and waiting for responses by threads on other CPUs
|
|
|
|
* (ie. smp_tlb_shootdown()).
|
2010-04-20 12:22:06 +00:00
|
|
|
*
|
|
|
|
* For the !SMP case it just needs to handle the former problem.
|
2009-08-13 17:09:45 +00:00
|
|
|
*/
|
2010-04-20 12:22:06 +00:00
|
|
|
#ifdef SMP
|
2010-04-19 23:27:54 +00:00
|
|
|
mtx_lock_spin(&smp_ipi_mtx);
|
2010-04-20 12:22:06 +00:00
|
|
|
#else
|
|
|
|
spinlock_enter();
|
|
|
|
#endif
|
2009-08-13 17:09:45 +00:00
|
|
|
|
1996-08-19 20:07:07 +00:00
|
|
|
/* cpu_boot(howto); */ /* doesn't do anything at the moment */
|
1996-08-19 02:19:23 +00:00
|
|
|
cpu_reset();
|
1999-08-21 06:24:40 +00:00
|
|
|
/* NOTREACHED */ /* assuming reset worked */
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
|
|
|
|
2016-07-05 18:34:34 +00:00
|
|
|
#if defined(WITNESS) || defined(INVARIANT_SUPPORT)
|
2012-12-07 08:25:08 +00:00
|
|
|
static int kassert_warn_only = 0;
|
2012-12-10 23:11:26 +00:00
|
|
|
#ifdef KDB
|
|
|
|
static int kassert_do_kdb = 0;
|
|
|
|
#endif
|
2012-12-07 08:25:08 +00:00
|
|
|
#ifdef KTR
|
|
|
|
static int kassert_do_ktr = 0;
|
|
|
|
#endif
|
|
|
|
static int kassert_do_log = 1;
|
|
|
|
static int kassert_log_pps_limit = 4;
|
|
|
|
static int kassert_log_mute_at = 0;
|
|
|
|
static int kassert_log_panic_at = 0;
|
|
|
|
static int kassert_warnings = 0;
|
|
|
|
|
|
|
|
SYSCTL_NODE(_debug, OID_AUTO, kassert, CTLFLAG_RW, NULL, "kassert options");
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, warn_only, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_warn_only, 0,
|
|
|
|
"KASSERT triggers a panic (1) or just a warning (0)");
|
|
|
|
|
2012-12-10 23:11:26 +00:00
|
|
|
#ifdef KDB
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, do_kdb, CTLFLAG_RWTUN,
|
2012-12-10 23:11:26 +00:00
|
|
|
&kassert_do_kdb, 0, "KASSERT will enter the debugger");
|
|
|
|
#endif
|
|
|
|
|
2012-12-07 08:25:08 +00:00
|
|
|
#ifdef KTR
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_UINT(_debug_kassert, OID_AUTO, do_ktr, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_do_ktr, 0,
|
|
|
|
"KASSERT does a KTR, set this to the KTRMASK you want");
|
|
|
|
#endif
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, do_log, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_do_log, 0, "KASSERT triggers a panic (1) or just a warning (0)");
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, warnings, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_warnings, 0, "number of KASSERTs that have been triggered");
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_panic_at, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_panic_at, 0, "max number of KASSERTS before we will panic");
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_pps_limit, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_pps_limit, 0, "limit number of log messages per second");
|
|
|
|
|
2014-06-28 03:56:17 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_mute_at, CTLFLAG_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_mute_at, 0, "max number of KASSERTS to log");
|
|
|
|
|
|
|
|
static int kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS);
|
|
|
|
|
|
|
|
SYSCTL_PROC(_debug_kassert, OID_AUTO, kassert,
|
|
|
|
CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE, NULL, 0,
|
|
|
|
kassert_sysctl_kassert, "I", "set to trigger a test kassert");
|
|
|
|
|
|
|
|
static int
|
|
|
|
kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
int error, i;
|
|
|
|
|
|
|
|
error = sysctl_wire_old_buffer(req, sizeof(int));
|
|
|
|
if (error == 0) {
|
|
|
|
i = 0;
|
|
|
|
error = sysctl_handle_int(oidp, &i, 0, req);
|
|
|
|
}
|
|
|
|
if (error != 0 || req->newptr == NULL)
|
|
|
|
return (error);
|
|
|
|
KASSERT(0, ("kassert_sysctl_kassert triggered kassert %d", i));
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called by KASSERT, this decides if we will panic
|
|
|
|
* or if we will log via printf and/or ktr.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
kassert_panic(const char *fmt, ...)
|
|
|
|
{
|
|
|
|
static char buf[256];
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
(void)vsnprintf(buf, sizeof(buf), fmt, ap);
|
|
|
|
va_end(ap);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* panic if we're not just warning, or if we've exceeded
|
|
|
|
* kassert_log_panic_at warnings.
|
|
|
|
*/
|
|
|
|
if (!kassert_warn_only ||
|
|
|
|
(kassert_log_panic_at > 0 &&
|
|
|
|
kassert_warnings >= kassert_log_panic_at)) {
|
|
|
|
va_start(ap, fmt);
|
|
|
|
vpanic(fmt, ap);
|
|
|
|
/* NORETURN */
|
|
|
|
}
|
|
|
|
#ifdef KTR
|
|
|
|
if (kassert_do_ktr)
|
|
|
|
CTR0(ktr_mask, buf);
|
|
|
|
#endif /* KTR */
|
|
|
|
/*
|
|
|
|
* log if we've not yet met the mute limit.
|
|
|
|
*/
|
|
|
|
if (kassert_do_log &&
|
|
|
|
(kassert_log_mute_at == 0 ||
|
|
|
|
kassert_warnings < kassert_log_mute_at)) {
|
|
|
|
static struct timeval lasterr;
|
|
|
|
static int curerr;
|
|
|
|
|
|
|
|
if (ppsratecheck(&lasterr, &curerr, kassert_log_pps_limit)) {
|
|
|
|
printf("KASSERT failed: %s\n", buf);
|
|
|
|
kdb_backtrace();
|
|
|
|
}
|
|
|
|
}
|
2012-12-10 23:11:26 +00:00
|
|
|
#ifdef KDB
|
|
|
|
if (kassert_do_kdb) {
|
|
|
|
kdb_enter(KDB_WHY_KASSERT, buf);
|
|
|
|
}
|
|
|
|
#endif
|
2012-12-07 08:25:08 +00:00
|
|
|
atomic_add_int(&kassert_warnings, 1);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
1996-08-19 02:19:23 +00:00
|
|
|
/*
|
|
|
|
* Panic is called on unresolvable fatal errors. It prints "panic: mesg",
|
|
|
|
* and then reboots. If we are called twice, then we avoid trying to sync
|
|
|
|
* the disks as this often leads to recursive panics.
|
|
|
|
*/
|
|
|
|
void
|
2004-06-06 21:26:49 +00:00
|
|
|
panic(const char *fmt, ...)
|
2012-12-07 08:25:08 +00:00
|
|
|
{
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
vpanic(fmt, ap);
|
|
|
|
}
|
|
|
|
|
2015-04-24 03:17:21 +00:00
|
|
|
void
|
2012-12-07 08:25:08 +00:00
|
|
|
vpanic(const char *fmt, va_list ap)
|
1996-08-19 02:19:23 +00:00
|
|
|
{
|
2010-10-09 08:07:49 +00:00
|
|
|
#ifdef SMP
|
panic: add a switch and infrastructure for stopping other CPUs in SMP case
Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.
Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state
Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.
This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.
The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.
PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)
2011-12-11 21:02:01 +00:00
|
|
|
cpuset_t other_cpus;
|
2010-10-09 08:07:49 +00:00
|
|
|
#endif
|
2002-07-17 02:23:44 +00:00
|
|
|
struct thread *td = curthread;
|
2002-09-19 18:49:46 +00:00
|
|
|
int bootopt, newpanic;
|
1998-09-06 06:25:18 +00:00
|
|
|
static char buf[256];
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2012-11-25 14:22:08 +00:00
|
|
|
spinlock_enter();
|
panic: add a switch and infrastructure for stopping other CPUs in SMP case
Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.
Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state
Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.
This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.
The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.
PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)
2011-12-11 21:02:01 +00:00
|
|
|
|
2000-09-07 01:33:02 +00:00
|
|
|
#ifdef SMP
|
2001-08-21 22:55:20 +00:00
|
|
|
/*
|
2012-11-25 14:22:08 +00:00
|
|
|
* stop_cpus_hard(other_cpus) should prevent multiple CPUs from
|
|
|
|
* concurrently entering panic. Only the winner will proceed
|
|
|
|
* further.
|
2001-08-21 22:55:20 +00:00
|
|
|
*/
|
2012-11-25 14:22:08 +00:00
|
|
|
if (panicstr == NULL && !kdb_active) {
|
|
|
|
other_cpus = all_cpus;
|
|
|
|
CPU_CLR(PCPU_GET(cpuid), &other_cpus);
|
|
|
|
stop_cpus_hard(other_cpus);
|
panic: add a switch and infrastructure for stopping other CPUs in SMP case
Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.
Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state
Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.
This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.
The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.
PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)
2011-12-11 21:02:01 +00:00
|
|
|
}
|
2017-01-14 22:16:03 +00:00
|
|
|
#endif
|
2012-11-25 14:22:08 +00:00
|
|
|
|
|
|
|
/*
|
2015-05-02 00:27:58 +00:00
|
|
|
* Ensure that the scheduler is stopped while panicking, even if panic
|
|
|
|
* has been entered from kdb.
|
2012-11-25 14:22:08 +00:00
|
|
|
*/
|
|
|
|
td->td_stopsched = 1;
|
2000-09-07 01:33:02 +00:00
|
|
|
|
2011-06-08 19:28:59 +00:00
|
|
|
bootopt = RB_AUTOBOOT;
|
2002-09-19 18:49:46 +00:00
|
|
|
newpanic = 0;
|
1996-08-19 02:19:23 +00:00
|
|
|
if (panicstr)
|
|
|
|
bootopt |= RB_NOSYNC;
|
2002-09-19 18:49:46 +00:00
|
|
|
else {
|
2011-06-08 19:28:59 +00:00
|
|
|
bootopt |= RB_DUMP;
|
1996-08-19 02:19:23 +00:00
|
|
|
panicstr = fmt;
|
2002-09-19 18:49:46 +00:00
|
|
|
newpanic = 1;
|
|
|
|
}
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2003-06-15 11:43:00 +00:00
|
|
|
if (newpanic) {
|
|
|
|
(void)vsnprintf(buf, sizeof(buf), fmt, ap);
|
1998-09-06 06:25:18 +00:00
|
|
|
panicstr = buf;
|
2011-12-17 15:11:22 +00:00
|
|
|
cngrab();
|
2004-06-06 21:26:49 +00:00
|
|
|
printf("panic: %s\n", buf);
|
2003-06-15 11:43:00 +00:00
|
|
|
} else {
|
|
|
|
printf("panic: ");
|
|
|
|
vprintf(fmt, ap);
|
2004-06-06 21:26:49 +00:00
|
|
|
printf("\n");
|
2003-06-15 11:43:00 +00:00
|
|
|
}
|
1997-05-24 18:35:44 +00:00
|
|
|
#ifdef SMP
|
2004-08-20 17:24:52 +00:00
|
|
|
printf("cpuid = %d\n", PCPU_GET(cpuid));
|
2000-11-29 01:33:15 +00:00
|
|
|
#endif
|
2017-03-06 22:32:56 +00:00
|
|
|
printf("time = %jd\n", (intmax_t )time_second);
|
2004-07-10 21:36:01 +00:00
|
|
|
#ifdef KDB
|
2002-09-19 18:49:46 +00:00
|
|
|
if (newpanic && trace_on_panic)
|
2004-07-10 21:36:01 +00:00
|
|
|
kdb_backtrace();
|
1996-08-19 02:19:23 +00:00
|
|
|
if (debugger_on_panic)
|
2007-12-25 17:52:02 +00:00
|
|
|
kdb_enter(KDB_WHY_PANIC, "panic");
|
1996-08-19 02:19:23 +00:00
|
|
|
#endif
|
Commit 14/14 of sched_lock decomposition.
- Use thread_lock() rather than sched_lock for per-thread scheduling
sychronization.
- Use the per-process spinlock rather than the sched_lock for per-process
scheduling synchronization.
Tested by: kris, current@
Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc.
Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)
2007-06-05 00:00:57 +00:00
|
|
|
/*thread_lock(td); */
|
2002-07-17 02:23:44 +00:00
|
|
|
td->td_flags |= TDF_INPANIC;
|
Commit 14/14 of sched_lock decomposition.
- Use thread_lock() rather than sched_lock for per-thread scheduling
sychronization.
- Use the per-process spinlock rather than the sched_lock for per-process
scheduling synchronization.
Tested by: kris, current@
Tested on: i386, amd64, ULE, 4BSD, libthr, libkse, PREEMPTION, etc.
Discussed with: kris, attilio, kmacy, jhb, julian, bde (small parts each)
2007-06-05 00:00:57 +00:00
|
|
|
/* thread_unlock(td); */
|
2001-10-19 23:32:03 +00:00
|
|
|
if (!sync_on_panic)
|
|
|
|
bootopt |= RB_NOSYNC;
|
2010-10-18 04:30:27 +00:00
|
|
|
kern_reboot(bootopt);
|
1996-08-19 02:19:23 +00:00
|
|
|
}
|
|
|
|
|
1999-01-30 19:28:30 +00:00
|
|
|
/*
|
|
|
|
* Support for poweroff delay.
|
2009-09-10 18:24:59 +00:00
|
|
|
*
|
|
|
|
* Please note that setting this delay too short might power off your machine
|
|
|
|
* before the write cache on your hard disk has been flushed, leading to
|
|
|
|
* soft-updates inconsistencies.
|
1999-01-30 19:28:30 +00:00
|
|
|
*/
|
1999-12-07 04:35:37 +00:00
|
|
|
#ifndef POWEROFF_DELAY
|
|
|
|
# define POWEROFF_DELAY 5000
|
|
|
|
#endif
|
|
|
|
static int poweroff_delay = POWEROFF_DELAY;
|
|
|
|
|
1999-01-30 19:28:30 +00:00
|
|
|
SYSCTL_INT(_kern_shutdown, OID_AUTO, poweroff_delay, CTLFLAG_RW,
|
2011-12-13 00:38:50 +00:00
|
|
|
&poweroff_delay, 0, "Delay before poweroff to write disk caches (msec)");
|
1999-01-30 19:28:30 +00:00
|
|
|
|
2003-02-14 12:44:48 +00:00
|
|
|
static void
|
1999-08-21 06:24:40 +00:00
|
|
|
poweroff_wait(void *junk, int howto)
|
1999-01-30 19:28:30 +00:00
|
|
|
{
|
2003-02-14 12:44:48 +00:00
|
|
|
|
|
|
|
if (!(howto & RB_POWEROFF) || poweroff_delay <= 0)
|
1999-01-30 19:28:30 +00:00
|
|
|
return;
|
|
|
|
DELAY(poweroff_delay * 1000);
|
|
|
|
}
|
2000-01-07 08:36:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some system processes (e.g. syncer) need to be stopped at appropriate
|
|
|
|
* points in their main loops prior to a system shutdown, so that they
|
|
|
|
* won't interfere with the shutdown process (e.g. by holding a disk buf
|
|
|
|
* to cause sync to fail). For each of these system processes, register
|
|
|
|
* shutdown_kproc() as a handler for one of shutdown events.
|
|
|
|
*/
|
|
|
|
static int kproc_shutdown_wait = 60;
|
|
|
|
SYSCTL_INT(_kern_shutdown, OID_AUTO, kproc_shutdown_wait, CTLFLAG_RW,
|
2011-12-13 00:38:50 +00:00
|
|
|
&kproc_shutdown_wait, 0, "Max wait time (sec) to stop for each process");
|
2000-01-07 08:36:44 +00:00
|
|
|
|
|
|
|
void
|
2000-12-15 20:08:20 +00:00
|
|
|
kproc_shutdown(void *arg, int howto)
|
2000-01-07 08:36:44 +00:00
|
|
|
{
|
|
|
|
struct proc *p;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (panicstr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
p = (struct proc *)arg;
|
2016-05-31 15:27:33 +00:00
|
|
|
printf("Waiting (max %d seconds) for system process `%s' to stop... ",
|
2009-10-23 15:09:51 +00:00
|
|
|
kproc_shutdown_wait, p->p_comm);
|
2007-10-20 23:23:23 +00:00
|
|
|
error = kproc_suspend(p, kproc_shutdown_wait * hz);
|
2000-01-07 08:36:44 +00:00
|
|
|
|
|
|
|
if (error == EWOULDBLOCK)
|
2004-07-30 01:30:05 +00:00
|
|
|
printf("timed out\n");
|
2000-01-07 08:36:44 +00:00
|
|
|
else
|
2004-07-30 01:30:05 +00:00
|
|
|
printf("done\n");
|
2000-01-07 08:36:44 +00:00
|
|
|
}
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
|
2007-10-26 08:00:41 +00:00
|
|
|
void
|
|
|
|
kthread_shutdown(void *arg, int howto)
|
|
|
|
{
|
|
|
|
struct thread *td;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (panicstr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
td = (struct thread *)arg;
|
2016-05-31 15:27:33 +00:00
|
|
|
printf("Waiting (max %d seconds) for system thread `%s' to stop... ",
|
2009-10-23 15:09:51 +00:00
|
|
|
kproc_shutdown_wait, td->td_name);
|
2007-10-26 08:00:41 +00:00
|
|
|
error = kthread_suspend(td, kproc_shutdown_wait * hz);
|
|
|
|
|
|
|
|
if (error == EWOULDBLOCK)
|
|
|
|
printf("timed out\n");
|
|
|
|
else
|
|
|
|
printf("done\n");
|
|
|
|
}
|
|
|
|
|
2012-11-01 17:01:05 +00:00
|
|
|
static char dumpdevname[sizeof(((struct cdev*)NULL)->si_name)];
|
|
|
|
SYSCTL_STRING(_kern_shutdown, OID_AUTO, dumpdevname, CTLFLAG_RD,
|
|
|
|
dumpdevname, 0, "Device for kernel dumps");
|
|
|
|
|
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
|
|
|
#ifdef EKCD
|
|
|
|
static struct kerneldumpcrypto *
|
|
|
|
kerneldumpcrypto_create(size_t blocksize, uint8_t encryption,
|
|
|
|
const uint8_t *key, uint32_t encryptedkeysize, const uint8_t *encryptedkey)
|
|
|
|
{
|
|
|
|
struct kerneldumpcrypto *kdc;
|
|
|
|
struct kerneldumpkey *kdk;
|
|
|
|
uint32_t dumpkeysize;
|
|
|
|
|
|
|
|
dumpkeysize = roundup2(sizeof(*kdk) + encryptedkeysize, blocksize);
|
|
|
|
kdc = malloc(sizeof(*kdc) + dumpkeysize, M_EKCD, M_WAITOK | M_ZERO);
|
|
|
|
|
|
|
|
arc4rand(kdc->kdc_iv, sizeof(kdc->kdc_iv), 0);
|
|
|
|
|
|
|
|
kdc->kdc_encryption = encryption;
|
|
|
|
switch (kdc->kdc_encryption) {
|
|
|
|
case KERNELDUMP_ENC_AES_256_CBC:
|
|
|
|
if (rijndael_makeKey(&kdc->kdc_ki, DIR_ENCRYPT, 256, key) <= 0)
|
|
|
|
goto failed;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto failed;
|
|
|
|
}
|
|
|
|
|
|
|
|
kdc->kdc_dumpkeysize = dumpkeysize;
|
|
|
|
kdk = kdc->kdc_dumpkey;
|
|
|
|
kdk->kdk_encryption = kdc->kdc_encryption;
|
|
|
|
memcpy(kdk->kdk_iv, kdc->kdc_iv, sizeof(kdk->kdk_iv));
|
|
|
|
kdk->kdk_encryptedkeysize = htod32(encryptedkeysize);
|
|
|
|
memcpy(kdk->kdk_encryptedkey, encryptedkey, encryptedkeysize);
|
|
|
|
|
|
|
|
return (kdc);
|
|
|
|
failed:
|
|
|
|
explicit_bzero(kdc, sizeof(*kdc) + dumpkeysize);
|
|
|
|
free(kdc, M_EKCD);
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2017-08-18 03:52:35 +00:00
|
|
|
static int
|
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
|
|
|
kerneldumpcrypto_init(struct kerneldumpcrypto *kdc)
|
|
|
|
{
|
|
|
|
uint8_t hash[SHA256_DIGEST_LENGTH];
|
|
|
|
SHA256_CTX ctx;
|
|
|
|
struct kerneldumpkey *kdk;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = 0;
|
|
|
|
|
|
|
|
if (kdc == NULL)
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When a user enters ddb it can write a crash dump multiple times.
|
|
|
|
* Each time it should be encrypted using a different IV.
|
|
|
|
*/
|
|
|
|
SHA256_Init(&ctx);
|
|
|
|
SHA256_Update(&ctx, kdc->kdc_iv, sizeof(kdc->kdc_iv));
|
|
|
|
SHA256_Final(hash, &ctx);
|
|
|
|
bcopy(hash, kdc->kdc_iv, sizeof(kdc->kdc_iv));
|
|
|
|
|
|
|
|
switch (kdc->kdc_encryption) {
|
|
|
|
case KERNELDUMP_ENC_AES_256_CBC:
|
|
|
|
if (rijndael_cipherInit(&kdc->kdc_ci, MODE_CBC,
|
|
|
|
kdc->kdc_iv) <= 0) {
|
|
|
|
error = EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
error = EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
kdc->kdc_nextoffset = 0;
|
|
|
|
|
|
|
|
kdk = kdc->kdc_dumpkey;
|
|
|
|
memcpy(kdk->kdk_iv, kdc->kdc_iv, sizeof(kdk->kdk_iv));
|
|
|
|
out:
|
|
|
|
explicit_bzero(hash, sizeof(hash));
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
static uint32_t
|
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
|
|
|
kerneldumpcrypto_dumpkeysize(const struct kerneldumpcrypto *kdc)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (kdc == NULL)
|
|
|
|
return (0);
|
|
|
|
return (kdc->kdc_dumpkeysize);
|
|
|
|
}
|
2017-08-18 04:04:09 +00:00
|
|
|
#endif /* EKCD */
|
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
|
|
|
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
/* Registration of dumpers */
|
|
|
|
int
|
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
|
|
|
set_dumper(struct dumperinfo *di, const char *devname, struct thread *td,
|
|
|
|
uint8_t encryption, const uint8_t *key, uint32_t encryptedkeysize,
|
|
|
|
const uint8_t *encryptedkey)
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
{
|
2012-11-02 18:57:38 +00:00
|
|
|
size_t wantcopy;
|
2014-11-11 04:48:09 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
error = priv_check(td, PRIV_SETDUMPER);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2003-02-14 12:44:48 +00:00
|
|
|
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
if (di == 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
|
|
|
error = 0;
|
|
|
|
goto cleanup;
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
}
|
|
|
|
if (dumper.dumper != NULL)
|
|
|
|
return (EBUSY);
|
|
|
|
dumper = *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
|
|
|
dumper.blockbuf = NULL;
|
|
|
|
dumper.kdc = NULL;
|
|
|
|
|
|
|
|
if (encryption != KERNELDUMP_ENC_NONE) {
|
|
|
|
#ifdef EKCD
|
|
|
|
dumper.kdc = kerneldumpcrypto_create(di->blocksize, encryption,
|
|
|
|
key, encryptedkeysize, encryptedkey);
|
|
|
|
if (dumper.kdc == NULL) {
|
|
|
|
error = EINVAL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
error = EOPNOTSUPP;
|
|
|
|
goto cleanup;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2012-11-02 18:57:38 +00:00
|
|
|
wantcopy = strlcpy(dumpdevname, devname, sizeof(dumpdevname));
|
|
|
|
if (wantcopy >= sizeof(dumpdevname)) {
|
2012-11-01 17:01:05 +00:00
|
|
|
printf("set_dumper: device name truncated from '%s' -> '%s'\n",
|
|
|
|
devname, dumpdevname);
|
|
|
|
}
|
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
|
|
|
|
2016-04-15 17:45:12 +00:00
|
|
|
dumper.blockbuf = malloc(di->blocksize, M_DUMPER, M_WAITOK | M_ZERO);
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
return (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
|
|
|
cleanup:
|
|
|
|
#ifdef EKCD
|
|
|
|
if (dumper.kdc != NULL) {
|
|
|
|
explicit_bzero(dumper.kdc, sizeof(*dumper.kdc) +
|
|
|
|
dumper.kdc->kdc_dumpkeysize);
|
|
|
|
free(dumper.kdc, M_EKCD);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
if (dumper.blockbuf != NULL) {
|
|
|
|
explicit_bzero(dumper.blockbuf, dumper.blocksize);
|
|
|
|
free(dumper.blockbuf, M_DUMPER);
|
|
|
|
}
|
|
|
|
explicit_bzero(&dumper, sizeof(dumper));
|
|
|
|
dumpdevname[0] = '\0';
|
|
|
|
return (error);
|
Here follows the new kernel dumping infrastructure.
Caveats:
The new savecore program is not complete in the sense that it emulates
enough of the old savecores features to do the job, but implements none
of the options yet.
I would appreciate if a userland hacker could help me out getting savecore
to do what we want it to do from a users point of view, compression,
email-notification, space reservation etc etc. (send me email if
you are interested).
Currently, savecore will scan all devices marked as "swap" or "dump" in
/etc/fstab _or_ any devices specified on the command-line.
All architectures but i386 lack an implementation of dumpsys(), but
looking at the i386 version it should be trivial for anybody familiar
with the platform(s) to provide this function.
Documentation is quite sparse at this time, more to come.
Details:
ATA and SCSI drivers should work as the dump formatting code has been
removed. The IDA, TWE and AAC have not yet been converted.
Dumpon now opens the device and uses ioctl(DIOCGKERNELDUMP) to set
the device as dumpdev. To implement the "off" argument, /dev/null
is used as the device.
Savecore will fail if handed any options since they are not (yet)
implemented. All devices marked "dump" or "swap" in /etc/fstab
will be scanned and dumps found will be saved to diskfiles
named from the MD5 hash of the header record. The header record
is dumped in readable format in the .info file. The kernel
is not saved. Only complete dumps will be saved.
All maintainer rights for this code are disclaimed: feel free to
improve and extend.
Sponsored by: DARPA, NAI Labs
2002-03-31 22:37:00 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
static int
|
|
|
|
dump_check_bounds(struct dumperinfo *di, off_t offset, size_t length)
|
2008-01-28 19:04:07 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
if (length != 0 && (offset < di->mediaoffset ||
|
|
|
|
offset - di->mediaoffset + length > di->mediasize)) {
|
2011-09-12 20:39:31 +00:00
|
|
|
printf("Attempt to write outside dump device boundaries.\n"
|
|
|
|
"offset(%jd), mediaoffset(%jd), length(%ju), mediasize(%jd).\n",
|
|
|
|
(intmax_t)offset, (intmax_t)di->mediaoffset,
|
|
|
|
(uintmax_t)length, (intmax_t)di->mediasize);
|
|
|
|
return (ENOSPC);
|
2008-01-28 19:04:07 +00:00
|
|
|
}
|
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
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
/* Call dumper with bounds checking. */
|
|
|
|
static int
|
|
|
|
dump_raw_write(struct dumperinfo *di, void *virtual, vm_offset_t physical,
|
|
|
|
off_t offset, size_t length)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = dump_check_bounds(di, offset, length);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
return (di->dumper(di->priv, virtual, physical, offset, length));
|
|
|
|
}
|
|
|
|
|
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
|
|
|
#ifdef EKCD
|
|
|
|
static int
|
|
|
|
dump_encrypt(struct kerneldumpcrypto *kdc, uint8_t *buf, size_t size)
|
|
|
|
{
|
|
|
|
|
|
|
|
switch (kdc->kdc_encryption) {
|
|
|
|
case KERNELDUMP_ENC_AES_256_CBC:
|
|
|
|
if (rijndael_blockEncrypt(&kdc->kdc_ci, &kdc->kdc_ki, buf,
|
|
|
|
8 * size, buf) <= 0) {
|
|
|
|
return (EIO);
|
|
|
|
}
|
|
|
|
if (rijndael_cipherInit(&kdc->kdc_ci, MODE_CBC,
|
|
|
|
buf + size - 16 /* IV size for AES-256-CBC */) <= 0) {
|
|
|
|
return (EIO);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Encrypt data and call dumper. */
|
|
|
|
static int
|
|
|
|
dump_encrypted_write(struct dumperinfo *di, void *virtual, vm_offset_t physical,
|
|
|
|
off_t offset, size_t length)
|
|
|
|
{
|
|
|
|
static uint8_t buf[KERNELDUMP_BUFFER_SIZE];
|
|
|
|
struct kerneldumpcrypto *kdc;
|
|
|
|
int error;
|
|
|
|
size_t nbytes;
|
|
|
|
off_t nextoffset;
|
|
|
|
|
|
|
|
kdc = di->kdc;
|
|
|
|
|
|
|
|
error = dump_check_bounds(di, offset, length);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
/* Signal completion. */
|
|
|
|
if (virtual == NULL && physical == 0 && offset == 0 && length == 0) {
|
|
|
|
return (di->dumper(di->priv, virtual, physical, offset,
|
|
|
|
length));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Data have to be aligned to block size. */
|
|
|
|
if ((length % di->blocksize) != 0)
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Data have to be written continuously becase we're encrypting using
|
|
|
|
* CBC mode which has this assumption.
|
|
|
|
*/
|
|
|
|
if (kdc->kdc_nextoffset != 0 && kdc->kdc_nextoffset != offset)
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
nextoffset = offset + (off_t)length;
|
|
|
|
|
|
|
|
while (length > 0) {
|
|
|
|
nbytes = MIN(length, sizeof(buf));
|
|
|
|
bcopy(virtual, buf, nbytes);
|
|
|
|
|
|
|
|
if (dump_encrypt(kdc, buf, nbytes) != 0)
|
|
|
|
return (EIO);
|
|
|
|
|
|
|
|
error = di->dumper(di->priv, buf, physical, offset, nbytes);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
offset += nbytes;
|
|
|
|
virtual = (void *)((uint8_t *)virtual + nbytes);
|
|
|
|
length -= nbytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
kdc->kdc_nextoffset = nextoffset;
|
|
|
|
|
|
|
|
return (0);
|
2008-01-28 19:04:07 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
static int
|
2017-08-18 04:04:09 +00:00
|
|
|
dump_write_key(struct dumperinfo *di, vm_offset_t physical, off_t offset)
|
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
|
|
|
{
|
2017-08-18 04:04:09 +00:00
|
|
|
struct kerneldumpcrypto *kdc;
|
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
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
kdc = di->kdc;
|
|
|
|
if (kdc == NULL)
|
|
|
|
return (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
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
return (dump_raw_write(di, kdc->kdc_dumpkey, physical, offset,
|
|
|
|
kdc->kdc_dumpkeysize));
|
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
|
|
|
}
|
2017-08-18 04:04:09 +00:00
|
|
|
#endif /* EKCD */
|
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
|
|
|
|
2016-04-15 17:45:12 +00:00
|
|
|
int
|
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
|
|
|
dump_write(struct dumperinfo *di, void *virtual, vm_offset_t physical,
|
|
|
|
off_t offset, size_t length)
|
|
|
|
{
|
|
|
|
|
|
|
|
#ifdef EKCD
|
|
|
|
if (di->kdc != NULL) {
|
|
|
|
return (dump_encrypted_write(di, virtual, physical, offset,
|
|
|
|
length));
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return (dump_raw_write(di, virtual, physical, offset, length));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2017-08-18 04:07:25 +00:00
|
|
|
dump_write_header(struct dumperinfo *di, struct kerneldumpheader *kdh,
|
|
|
|
vm_offset_t physical, off_t offset)
|
2016-04-15 17:45:12 +00:00
|
|
|
{
|
2017-08-18 04:07:25 +00:00
|
|
|
void *buf;
|
|
|
|
size_t hdrsz;
|
2016-04-15 17:45:12 +00:00
|
|
|
|
2017-08-18 04:07:25 +00:00
|
|
|
hdrsz = sizeof(*kdh);
|
|
|
|
if (hdrsz > di->blocksize)
|
2016-04-15 17:45:12 +00:00
|
|
|
return (ENOMEM);
|
|
|
|
|
2017-08-18 04:07:25 +00:00
|
|
|
if (hdrsz == di->blocksize)
|
|
|
|
buf = kdh;
|
|
|
|
else {
|
|
|
|
buf = di->blockbuf;
|
|
|
|
memset(buf, 0, di->blocksize);
|
|
|
|
memcpy(buf, kdh, hdrsz);
|
2016-04-15 17:45:12 +00:00
|
|
|
}
|
|
|
|
|
2017-08-18 04:07:25 +00:00
|
|
|
return (dump_raw_write(di, buf, physical, offset, di->blocksize));
|
2016-04-15 17:45:12 +00:00
|
|
|
}
|
|
|
|
|
2017-08-18 03:52:35 +00:00
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do some preliminary setup for a kernel dump: verify that we have enough space
|
|
|
|
* on the dump device, write the leading header, and optionally write the crypto
|
|
|
|
* key.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
dump_start(struct dumperinfo *di, struct kerneldumpheader *kdh, off_t *dumplop)
|
|
|
|
{
|
|
|
|
uint64_t dumpsize;
|
2017-08-18 04:04:09 +00:00
|
|
|
uint32_t keysize;
|
2017-08-18 03:52:35 +00:00
|
|
|
int error;
|
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
#ifdef EKCD
|
2017-08-18 03:52:35 +00:00
|
|
|
error = kerneldumpcrypto_init(di->kdc);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2017-08-18 04:04:09 +00:00
|
|
|
keysize = kerneldumpcrypto_dumpkeysize(di->kdc);
|
|
|
|
#else
|
|
|
|
keysize = 0;
|
|
|
|
#endif
|
2017-08-18 03:52:35 +00:00
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
dumpsize = dtoh64(kdh->dumplength) + 2 * di->blocksize + keysize;
|
2017-08-18 03:52:35 +00:00
|
|
|
if (di->mediasize < SIZEOF_METADATA + dumpsize)
|
|
|
|
return (E2BIG);
|
|
|
|
|
|
|
|
*dumplop = di->mediaoffset + di->mediasize - dumpsize;
|
|
|
|
|
|
|
|
error = dump_write_header(di, kdh, 0, *dumplop);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
*dumplop += di->blocksize;
|
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
#ifdef EKCD
|
2017-08-18 03:52:35 +00:00
|
|
|
error = dump_write_key(di, 0, *dumplop);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2017-08-18 04:04:09 +00:00
|
|
|
*dumplop += keysize;
|
|
|
|
#endif
|
2017-08-18 03:52:35 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write the trailing kernel dump header and signal to the lower layers that the
|
|
|
|
* dump has completed.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
dump_finish(struct dumperinfo *di, struct kerneldumpheader *kdh, off_t dumplo)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = dump_write_header(di, kdh, 0, dumplo);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
(void)dump_write(di, NULL, 0, 0, 0);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2008-10-01 22:08:53 +00:00
|
|
|
void
|
2017-08-18 04:04:09 +00:00
|
|
|
dump_init_header(const struct dumperinfo *di, struct kerneldumpheader *kdh,
|
|
|
|
char *magic, uint32_t archver, uint64_t dumplen)
|
2008-10-01 22:08:53 +00:00
|
|
|
{
|
2017-07-15 20:53:08 +00:00
|
|
|
size_t dstsize;
|
2008-10-01 22:08:53 +00:00
|
|
|
|
|
|
|
bzero(kdh, sizeof(*kdh));
|
2015-05-19 16:23:47 +00:00
|
|
|
strlcpy(kdh->magic, magic, sizeof(kdh->magic));
|
|
|
|
strlcpy(kdh->architecture, MACHINE_ARCH, sizeof(kdh->architecture));
|
2008-10-01 22:08:53 +00:00
|
|
|
kdh->version = htod32(KERNELDUMPVERSION);
|
|
|
|
kdh->architectureversion = htod32(archver);
|
|
|
|
kdh->dumplength = htod64(dumplen);
|
|
|
|
kdh->dumptime = htod64(time_second);
|
2017-08-18 04:04:09 +00:00
|
|
|
#ifdef EKCD
|
|
|
|
kdh->dumpkeysize = htod32(kerneldumpcrypto_dumpkeysize(di->kdc));
|
|
|
|
#else
|
|
|
|
kdh->dumpkeysize = 0;
|
|
|
|
#endif
|
|
|
|
kdh->blocksize = htod32(di->blocksize);
|
2015-05-19 16:23:47 +00:00
|
|
|
strlcpy(kdh->hostname, prison0.pr_hostname, sizeof(kdh->hostname));
|
2017-07-15 20:53:08 +00:00
|
|
|
dstsize = sizeof(kdh->versionstring);
|
|
|
|
if (strlcpy(kdh->versionstring, version, dstsize) >= dstsize)
|
|
|
|
kdh->versionstring[dstsize - 2] = '\n';
|
2008-10-01 22:08:53 +00:00
|
|
|
if (panicstr != NULL)
|
2015-05-19 16:23:47 +00:00
|
|
|
strlcpy(kdh->panicstring, panicstr, sizeof(kdh->panicstring));
|
2008-10-01 22:08:53 +00:00
|
|
|
kdh->parity = kerneldump_parity(kdh);
|
|
|
|
}
|
2016-06-06 20:57:24 +00:00
|
|
|
|
|
|
|
#ifdef DDB
|
|
|
|
DB_SHOW_COMMAND(panic, db_show_panic)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (panicstr == NULL)
|
|
|
|
db_printf("panicstr not set\n");
|
|
|
|
else
|
|
|
|
db_printf("panic: %s\n", panicstr);
|
|
|
|
}
|
|
|
|
#endif
|