1996-08-19 02:19:23 +00:00
|
|
|
/*-
|
2017-11-20 19:43:44 +00:00
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*
|
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"
|
2019-05-06 18:24:07 +00:00
|
|
|
#include "opt_printf.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>
|
2018-01-08 21:27:41 +00:00
|
|
|
#include <sys/compressor.h>
|
2001-06-25 18:30:42 +00:00
|
|
|
#include <sys/cons.h>
|
2019-05-06 18:24:07 +00:00
|
|
|
#include <sys/disk.h>
|
2001-06-25 18:30:42 +00:00
|
|
|
#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>
|
2018-05-06 00:22:38 +00:00
|
|
|
#include <sys/mbuf.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>
|
2019-05-06 18:24:07 +00:00
|
|
|
#include <sys/sbuf.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>
|
2018-03-22 20:47:25 +00:00
|
|
|
#include <sys/taskqueue.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
|
|
|
|
2019-05-23 20:12:24 +00:00
|
|
|
#include <crypto/chacha20/chacha.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 <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
|
2020-04-26 00:41:29 +00:00
|
|
|
int debugger_on_panic = 0;
|
1996-08-19 02:19:23 +00:00
|
|
|
#else
|
2020-04-26 00:41:29 +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
|
|
|
|
2018-11-01 21:34:17 +00:00
|
|
|
int debugger_on_trap = 0;
|
|
|
|
SYSCTL_INT(_debug, OID_AUTO, debugger_on_trap,
|
|
|
|
CTLFLAG_RWTUN | CTLFLAG_SECURE,
|
|
|
|
&debugger_on_trap, 0, "Run debugger on kernel trap before panic");
|
|
|
|
|
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;
|
2018-04-24 18:54:20 +00:00
|
|
|
static bool trace_all_panics = true;
|
2002-09-19 18:49:46 +00:00
|
|
|
#else
|
2010-10-01 09:34:41 +00:00
|
|
|
static int trace_on_panic = 0;
|
2018-04-24 18:54:20 +00:00
|
|
|
static bool trace_all_panics = false;
|
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");
|
2018-04-24 18:54:20 +00:00
|
|
|
SYSCTL_BOOL(_debug, OID_AUTO, trace_all_panics, CTLFLAG_RWTUN,
|
|
|
|
&trace_all_panics, 0, "Print stack traces on secondary kernel panics");
|
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");
|
|
|
|
|
2017-11-14 00:29:14 +00:00
|
|
|
static bool poweroff_on_panic = 0;
|
|
|
|
SYSCTL_BOOL(_kern, OID_AUTO, poweroff_on_panic, CTLFLAG_RWTUN,
|
|
|
|
&poweroff_on_panic, 0, "Do a power off instead of a reboot on a panic");
|
|
|
|
|
|
|
|
static bool powercycle_on_panic = 0;
|
|
|
|
SYSCTL_BOOL(_kern, OID_AUTO, powercycle_on_panic, CTLFLAG_RWTUN,
|
|
|
|
&powercycle_on_panic, 0, "Do a power cycle instead of a reboot on a panic");
|
|
|
|
|
2020-02-26 14:26:36 +00:00
|
|
|
static SYSCTL_NODE(_kern, OID_AUTO, shutdown, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
|
2011-11-07 15:43:11 +00:00
|
|
|
"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,
|
2020-03-02 15:30:52 +00:00
|
|
|
&show_busybufs, 0,
|
|
|
|
"Show busy buffers during shutdown");
|
2011-09-08 12:56:26 +00:00
|
|
|
|
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];
|
2019-05-23 20:12:24 +00:00
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
keyInstance aes_ki;
|
|
|
|
cipherInstance aes_ci;
|
|
|
|
} u_aes;
|
|
|
|
struct chacha_ctx u_chacha;
|
|
|
|
} u;
|
|
|
|
#define kdc_ki u.u_aes.aes_ki
|
|
|
|
#define kdc_ci u.u_aes.aes_ci
|
|
|
|
#define kdc_chacha u.u_chacha
|
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
|
|
|
uint32_t kdc_dumpkeysize;
|
|
|
|
struct kerneldumpkey kdc_dumpkey[];
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
struct kerneldumpcomp {
|
2018-02-13 19:28:02 +00:00
|
|
|
uint8_t kdc_format;
|
2018-01-08 21:27:41 +00:00
|
|
|
struct compressor *kdc_stream;
|
|
|
|
uint8_t *kdc_buf;
|
|
|
|
size_t kdc_resid;
|
2017-10-25 00:51:00 +00:00
|
|
|
};
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
static struct kerneldumpcomp *kerneldumpcomp_create(struct dumperinfo *di,
|
2017-10-25 00:51:00 +00:00
|
|
|
uint8_t compression);
|
2018-01-08 21:27:41 +00:00
|
|
|
static void kerneldumpcomp_destroy(struct dumperinfo *di);
|
|
|
|
static int kerneldumpcomp_write_cb(void *base, size_t len, off_t off, void *arg);
|
2017-10-25 00:51:00 +00:00
|
|
|
|
|
|
|
static int kerneldump_gzlevel = 6;
|
|
|
|
SYSCTL_INT(_kern, OID_AUTO, kerneldump_gzlevel, CTLFLAG_RWTUN,
|
|
|
|
&kerneldump_gzlevel, 0,
|
2018-01-08 21:27:41 +00:00
|
|
|
"Kernel crash dump compression level");
|
2017-10-25 00:51:00 +00:00
|
|
|
|
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.
|
|
|
|
*/
|
2020-01-12 06:09:10 +00:00
|
|
|
const char *panicstr;
|
|
|
|
bool __read_frequently panicked;
|
1996-08-19 02:19:23 +00:00
|
|
|
|
2019-12-04 21:26:03 +00:00
|
|
|
int __read_mostly dumping; /* system is dumping */
|
2006-02-06 10:12:00 +00:00
|
|
|
int rebooting; /* system is rebooting */
|
2019-05-06 18:24:07 +00:00
|
|
|
/*
|
|
|
|
* Used to serialize between sysctl kern.shutdown.dumpdevname and list
|
|
|
|
* modifications via ioctl.
|
|
|
|
*/
|
|
|
|
static struct mtx dumpconf_list_lk;
|
|
|
|
MTX_SYSINIT(dumper_configs, &dumpconf_list_lk, "dumper config list", MTX_DEF);
|
|
|
|
|
|
|
|
/* Our selected dumper(s). */
|
|
|
|
static TAILQ_HEAD(dumpconflist, dumperinfo) dumper_configs =
|
|
|
|
TAILQ_HEAD_INITIALIZER(dumper_configs);
|
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) {
|
2018-03-21 14:46:54 +00:00
|
|
|
if (uap->opt & RB_REROOT)
|
2015-09-18 17:32:22 +00:00
|
|
|
error = kern_reroot();
|
2018-03-21 14:46:54 +00:00
|
|
|
else
|
2015-09-18 17:32:22 +00:00
|
|
|
kern_reboot(uap->opt);
|
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
|
|
|
}
|
|
|
|
|
2018-03-22 20:47:25 +00:00
|
|
|
static void
|
|
|
|
shutdown_nice_task_fn(void *arg, int pending __unused)
|
|
|
|
{
|
|
|
|
int howto;
|
|
|
|
|
|
|
|
howto = (uintptr_t)arg;
|
|
|
|
/* Send a signal to init(8) and have it shutdown the world. */
|
|
|
|
PROC_LOCK(initproc);
|
|
|
|
if (howto & RB_POWEROFF)
|
|
|
|
kern_psignal(initproc, SIGUSR2);
|
|
|
|
else if (howto & RB_POWERCYCLE)
|
|
|
|
kern_psignal(initproc, SIGWINCH);
|
|
|
|
else if (howto & RB_HALT)
|
|
|
|
kern_psignal(initproc, SIGUSR1);
|
|
|
|
else
|
|
|
|
kern_psignal(initproc, SIGINT);
|
|
|
|
PROC_UNLOCK(initproc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct task shutdown_nice_task = TASK_INITIALIZER(0,
|
|
|
|
&shutdown_nice_task_fn, NULL);
|
|
|
|
|
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
|
|
|
|
2018-03-22 20:47:25 +00:00
|
|
|
if (initproc != NULL && !SCHEDULER_STOPPED()) {
|
|
|
|
shutdown_nice_task.ta_context = (void *)(uintptr_t)howto;
|
|
|
|
taskqueue_enqueue(taskqueue_fast, &shutdown_nice_task);
|
1996-08-19 02:19:23 +00:00
|
|
|
} else {
|
2018-03-22 20:47:25 +00:00
|
|
|
/*
|
|
|
|
* No init(8) running, or scheduler would not allow it
|
|
|
|
* to run, 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);
|
2019-05-06 18:24:07 +00:00
|
|
|
if (TAILQ_EMPTY(&dumper_configs))
|
2011-06-07 01:28:12 +00:00
|
|
|
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;
|
2019-05-06 18:24:07 +00:00
|
|
|
textdump_dumpsys(TAILQ_FIRST(&dumper_configs));
|
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
|
2019-05-06 18:24:07 +00:00
|
|
|
if (coredump) {
|
|
|
|
struct dumperinfo *di;
|
|
|
|
|
|
|
|
TAILQ_FOREACH(di, &dumper_configs, di_next) {
|
|
|
|
error = dumpsys(di);
|
|
|
|
if (error == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
2018-03-22 15:34:37 +00:00
|
|
|
/*
|
|
|
|
* Normal paths here don't hold Giant, but we can wind up here
|
|
|
|
* unexpectedly with it held. Drop it now so we don't have to
|
|
|
|
* drop and pick it up elsewhere. The paths it is locking will
|
|
|
|
* never be returned to, and it is preferable to preclude
|
|
|
|
* deadlock than to lock against code that won't ever
|
|
|
|
* continue.
|
|
|
|
*/
|
|
|
|
while (mtx_owned(&Giant))
|
|
|
|
mtx_unlock(&Giant);
|
|
|
|
|
2004-11-08 04:52:26 +00:00
|
|
|
#if defined(SMP)
|
2004-11-07 06:58:45 +00:00
|
|
|
/*
|
2017-11-25 23:41:05 +00:00
|
|
|
* Bind us to the first CPU so that all shutdown code runs there. Some
|
2004-11-07 06:58:45 +00:00
|
|
|
* 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);
|
2017-11-25 23:41:05 +00:00
|
|
|
sched_bind(curthread, CPU_FIRST());
|
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
|
|
|
thread_unlock(curthread);
|
2017-11-25 23:41:05 +00:00
|
|
|
KASSERT(PCPU_GET(cpuid) == CPU_FIRST(),
|
|
|
|
("boot: not running on cpu 0"));
|
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
|
|
|
}
|
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);
|
2020-01-03 22:29:58 +00:00
|
|
|
VOP_UNLOCK(vp);
|
2015-09-18 17:32:22 +00:00
|
|
|
error = vfs_busy(mp, 0);
|
|
|
|
vn_lock(vp, LK_SHARED | LK_RETRY);
|
|
|
|
vfs_rel(mp);
|
|
|
|
if (error != 0) {
|
2020-01-03 22:29:58 +00:00
|
|
|
VOP_UNLOCK(vp);
|
2015-09-18 17:32:22 +00:00
|
|
|
return (ENOENT);
|
|
|
|
}
|
2019-12-08 21:30:04 +00:00
|
|
|
if (VN_IS_DOOMED(vp)) {
|
2020-01-03 22:29:58 +00:00
|
|
|
VOP_UNLOCK(vp);
|
2015-09-18 17:32:22 +00:00
|
|
|
vfs_unbusy(mp);
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
}
|
2020-01-03 22:29:58 +00:00
|
|
|
VOP_UNLOCK(vp);
|
2015-09-18 17:32:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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");
|
2019-09-04 13:26:59 +00:00
|
|
|
|
|
|
|
wdog_kern_pat(WD_TO_NEVER);
|
|
|
|
|
1996-10-31 00:57:28 +00:00
|
|
|
switch (cngetc()) {
|
|
|
|
case -1: /* No console, just die */
|
|
|
|
cpu_halt();
|
|
|
|
/* NOTREACHED */
|
|
|
|
default:
|
|
|
|
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 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;
|
2018-04-24 18:47:35 +00:00
|
|
|
static int kassert_suppress_in_panic = 0;
|
2012-12-07 08:25:08 +00:00
|
|
|
static int kassert_warnings = 0;
|
|
|
|
|
2020-02-26 14:26:36 +00:00
|
|
|
SYSCTL_NODE(_debug, OID_AUTO, kassert, CTLFLAG_RW | CTLFLAG_MPSAFE, NULL,
|
|
|
|
"kassert options");
|
2012-12-07 08:25:08 +00:00
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
#ifdef KASSERT_PANIC_OPTIONAL
|
|
|
|
#define KASSERT_RWTUN CTLFLAG_RWTUN
|
|
|
|
#else
|
|
|
|
#define KASSERT_RWTUN CTLFLAG_RDTUN
|
|
|
|
#endif
|
|
|
|
|
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, warn_only, KASSERT_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_warn_only, 0,
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
"KASSERT triggers a panic (0) or just a warning (1)");
|
2012-12-07 08:25:08 +00:00
|
|
|
|
2012-12-10 23:11:26 +00:00
|
|
|
#ifdef KDB
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, do_kdb, KASSERT_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
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_UINT(_debug_kassert, OID_AUTO, do_ktr, KASSERT_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
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, do_log, KASSERT_RWTUN,
|
2018-04-24 18:59:40 +00:00
|
|
|
&kassert_do_log, 0,
|
|
|
|
"If warn_only is enabled, log (1) or do not log (0) assertion violations");
|
2012-12-07 08:25:08 +00:00
|
|
|
|
2019-10-21 12:21:56 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, warnings, CTLFLAG_RD | CTLFLAG_STATS,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_warnings, 0, "number of KASSERTs that have been triggered");
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_panic_at, KASSERT_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_panic_at, 0, "max number of KASSERTS before we will panic");
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_pps_limit, KASSERT_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_pps_limit, 0, "limit number of log messages per second");
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, log_mute_at, KASSERT_RWTUN,
|
2012-12-07 08:25:08 +00:00
|
|
|
&kassert_log_mute_at, 0, "max number of KASSERTS to log");
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
SYSCTL_INT(_debug_kassert, OID_AUTO, suppress_in_panic, KASSERT_RWTUN,
|
2018-04-21 17:05:00 +00:00
|
|
|
&kassert_suppress_in_panic, 0,
|
|
|
|
"KASSERTs will be suppressed while handling a panic");
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
#undef KASSERT_RWTUN
|
2018-04-21 17:05:00 +00:00
|
|
|
|
2012-12-07 08:25:08 +00:00
|
|
|
static int kassert_sysctl_kassert(SYSCTL_HANDLER_ARGS);
|
|
|
|
|
|
|
|
SYSCTL_PROC(_debug_kassert, OID_AUTO, kassert,
|
2020-02-26 14:26:36 +00:00
|
|
|
CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE | CTLFLAG_NEEDGIANT, NULL, 0,
|
|
|
|
kassert_sysctl_kassert, "I",
|
|
|
|
"set to trigger a test kassert");
|
2012-12-07 08:25:08 +00:00
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
#ifdef KASSERT_PANIC_OPTIONAL
|
2012-12-07 08:25:08 +00:00
|
|
|
/*
|
|
|
|
* 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);
|
|
|
|
|
2018-04-24 19:10:51 +00:00
|
|
|
/*
|
|
|
|
* If we are suppressing secondary panics, log the warning but do not
|
|
|
|
* re-enter panic/kdb.
|
|
|
|
*/
|
|
|
|
if (panicstr != NULL && kassert_suppress_in_panic) {
|
|
|
|
if (kassert_do_log) {
|
|
|
|
printf("KASSERT failed: %s\n", buf);
|
|
|
|
#ifdef KDB
|
|
|
|
if (trace_all_panics && trace_on_panic)
|
|
|
|
kdb_backtrace();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-12-07 08:25:08 +00:00
|
|
|
/*
|
|
|
|
* 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);
|
|
|
|
}
|
KASSERT: Make runtime optionality optional
Add an option, KASSERT_PANIC_OPTIONAL, that allows runtime KASSERT()
behavior changes. When this option is not enabled, code that allows
KASSERTs to become optional is not enabled, and all violated assertions
cause termination.
The runtime KASSERT behavior was added in r243980.
One important distinction here is that panic has __dead2
("attribute((noreturn))"), while kassert_panic does not. Static analyzers
like Coverity understand __dead2. Without it, KASSERTs go misunderstood,
resulting in many false positives that result from violation of program
invariants.
Reviewed by: jhb, jtl, np, vangyzen
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16835
2018-08-22 22:19:42 +00:00
|
|
|
#endif /* KASSERT_PANIC_OPTIONAL */
|
2012-12-07 08:25:08 +00:00
|
|
|
#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;
|
2020-01-12 06:09:10 +00:00
|
|
|
panicked = true;
|
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
|
2018-04-24 18:54:20 +00:00
|
|
|
if ((newpanic || trace_all_panics) && 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;
|
2017-11-14 00:29:14 +00:00
|
|
|
if (poweroff_on_panic)
|
|
|
|
bootopt |= RB_POWEROFF;
|
|
|
|
if (powercycle_on_panic)
|
|
|
|
bootopt |= RB_POWERCYCLE;
|
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
|
|
|
|
2017-10-25 15:30:44 +00:00
|
|
|
if ((howto & (RB_POWEROFF | RB_POWERCYCLE)) == 0 || 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");
|
|
|
|
}
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
static int
|
|
|
|
dumpdevname_sysctl_handler(SYSCTL_HANDLER_ARGS)
|
|
|
|
{
|
|
|
|
char buf[256];
|
|
|
|
struct dumperinfo *di;
|
|
|
|
struct sbuf sb;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = sysctl_wire_old_buffer(req, 0);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
sbuf_new_for_sysctl(&sb, buf, sizeof(buf), req);
|
|
|
|
|
|
|
|
mtx_lock(&dumpconf_list_lk);
|
|
|
|
TAILQ_FOREACH(di, &dumper_configs, di_next) {
|
|
|
|
if (di != TAILQ_FIRST(&dumper_configs))
|
|
|
|
sbuf_putc(&sb, ',');
|
|
|
|
sbuf_cat(&sb, di->di_devname);
|
|
|
|
}
|
|
|
|
mtx_unlock(&dumpconf_list_lk);
|
|
|
|
|
|
|
|
error = sbuf_finish(&sb);
|
|
|
|
sbuf_delete(&sb);
|
|
|
|
return (error);
|
|
|
|
}
|
2020-02-26 14:26:36 +00:00
|
|
|
SYSCTL_PROC(_kern_shutdown, OID_AUTO, dumpdevname,
|
|
|
|
CTLTYPE_STRING | CTLFLAG_RD | CTLFLAG_NEEDGIANT, &dumper_configs, 0,
|
|
|
|
dumpdevname_sysctl_handler, "A",
|
2019-05-06 18:24:07 +00:00
|
|
|
"Device(s) for kernel dumps");
|
2012-11-01 17:01:05 +00:00
|
|
|
|
2017-10-25 00:51:00 +00:00
|
|
|
static int _dump_append(struct dumperinfo *di, void *virtual,
|
|
|
|
vm_offset_t physical, size_t 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 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;
|
2019-05-23 20:12:24 +00:00
|
|
|
case KERNELDUMP_ENC_CHACHA20:
|
|
|
|
chacha_keysetup(&kdc->kdc_chacha, key, 256);
|
|
|
|
break;
|
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
|
|
|
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:
|
2020-06-25 20:17:34 +00:00
|
|
|
zfree(kdc, M_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
|
|
|
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;
|
2019-05-23 20:12:24 +00:00
|
|
|
case KERNELDUMP_ENC_CHACHA20:
|
|
|
|
chacha_ivsetup(&kdc->kdc_chacha, kdc->kdc_iv, NULL);
|
|
|
|
break;
|
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
|
|
|
default:
|
|
|
|
error = EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
static struct kerneldumpcomp *
|
|
|
|
kerneldumpcomp_create(struct dumperinfo *di, uint8_t compression)
|
2017-10-25 00:51:00 +00:00
|
|
|
{
|
2018-01-08 21:27:41 +00:00
|
|
|
struct kerneldumpcomp *kdcomp;
|
2018-02-13 19:28:02 +00:00
|
|
|
int format;
|
2017-10-25 00:51:00 +00:00
|
|
|
|
2018-02-13 19:28:02 +00:00
|
|
|
switch (compression) {
|
|
|
|
case KERNELDUMP_COMP_GZIP:
|
|
|
|
format = COMPRESS_GZIP;
|
|
|
|
break;
|
|
|
|
case KERNELDUMP_COMP_ZSTD:
|
|
|
|
format = COMPRESS_ZSTD;
|
|
|
|
break;
|
|
|
|
default:
|
2017-10-25 00:51:00 +00:00
|
|
|
return (NULL);
|
2018-02-13 19:28:02 +00:00
|
|
|
}
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
kdcomp = malloc(sizeof(*kdcomp), M_DUMPER, M_WAITOK | M_ZERO);
|
2018-02-13 19:28:02 +00:00
|
|
|
kdcomp->kdc_format = compression;
|
2018-01-08 21:27:41 +00:00
|
|
|
kdcomp->kdc_stream = compressor_init(kerneldumpcomp_write_cb,
|
2018-02-13 19:28:02 +00:00
|
|
|
format, di->maxiosize, kerneldump_gzlevel, di);
|
2018-01-08 21:27:41 +00:00
|
|
|
if (kdcomp->kdc_stream == NULL) {
|
|
|
|
free(kdcomp, M_DUMPER);
|
2017-10-25 00:51:00 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
2018-01-08 21:27:41 +00:00
|
|
|
kdcomp->kdc_buf = malloc(di->maxiosize, M_DUMPER, M_WAITOK | M_NODUMP);
|
|
|
|
return (kdcomp);
|
2017-10-25 00:51:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2018-01-08 21:27:41 +00:00
|
|
|
kerneldumpcomp_destroy(struct dumperinfo *di)
|
2017-10-25 00:51:00 +00:00
|
|
|
{
|
2018-01-08 21:27:41 +00:00
|
|
|
struct kerneldumpcomp *kdcomp;
|
2017-10-25 00:51:00 +00:00
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
kdcomp = di->kdcomp;
|
|
|
|
if (kdcomp == NULL)
|
2017-10-25 00:51:00 +00:00
|
|
|
return;
|
2018-01-08 21:27:41 +00:00
|
|
|
compressor_fini(kdcomp->kdc_stream);
|
2020-06-25 20:17:34 +00:00
|
|
|
zfree(kdcomp->kdc_buf, M_DUMPER);
|
2018-01-08 21:27:41 +00:00
|
|
|
free(kdcomp, M_DUMPER);
|
2017-10-25 00:51:00 +00:00
|
|
|
}
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
/*
|
|
|
|
* Must not be present on global list.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
free_single_dumper(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (di == NULL)
|
|
|
|
return;
|
|
|
|
|
2020-06-25 20:17:34 +00:00
|
|
|
zfree(di->blockbuf, M_DUMPER);
|
2019-05-06 18:24:07 +00:00
|
|
|
|
|
|
|
kerneldumpcomp_destroy(di);
|
|
|
|
|
|
|
|
#ifdef EKCD
|
2020-06-25 20:17:34 +00:00
|
|
|
zfree(di->kdcrypto, M_EKCD);
|
2019-05-06 18:24:07 +00:00
|
|
|
#endif
|
2020-06-25 20:17:34 +00:00
|
|
|
zfree(di, M_DUMPER);
|
2019-05-06 18:24:07 +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
|
2019-05-06 18:24:07 +00:00
|
|
|
dumper_insert(const struct dumperinfo *di_template, const char *devname,
|
|
|
|
const struct diocskerneldump_arg *kda)
|
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
|
|
|
{
|
2019-05-06 18:24:07 +00:00
|
|
|
struct dumperinfo *newdi, *listdi;
|
|
|
|
bool inserted;
|
|
|
|
uint8_t index;
|
2014-11-11 04:48:09 +00:00
|
|
|
int error;
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
index = kda->kda_index;
|
|
|
|
MPASS(index != KDA_REMOVE && index != KDA_REMOVE_DEV &&
|
|
|
|
index != KDA_REMOVE_ALL);
|
|
|
|
|
|
|
|
error = priv_check(curthread, PRIV_SETDUMPER);
|
2014-11-11 04:48:09 +00:00
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2003-02-14 12:44:48 +00:00
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
newdi = malloc(sizeof(*newdi) + strlen(devname) + 1, M_DUMPER, M_WAITOK
|
|
|
|
| M_ZERO);
|
|
|
|
memcpy(newdi, di_template, sizeof(*newdi));
|
|
|
|
newdi->blockbuf = NULL;
|
|
|
|
newdi->kdcrypto = NULL;
|
|
|
|
newdi->kdcomp = NULL;
|
|
|
|
strcpy(newdi->di_devname, devname);
|
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
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
if (kda->kda_encryption != KERNELDUMP_ENC_NONE) {
|
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
|
2019-05-06 18:24:07 +00:00
|
|
|
newdi->kdcrypto = kerneldumpcrypto_create(di_template->blocksize,
|
|
|
|
kda->kda_encryption, kda->kda_key,
|
|
|
|
kda->kda_encryptedkeysize, kda->kda_encryptedkey);
|
|
|
|
if (newdi->kdcrypto == NULL) {
|
Add support for encrypted kernel crash dumps.
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
|
|
|
error = EINVAL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
error = EOPNOTSUPP;
|
|
|
|
goto cleanup;
|
|
|
|
#endif
|
|
|
|
}
|
2019-05-06 18:24:07 +00:00
|
|
|
if (kda->kda_compression != KERNELDUMP_COMP_NONE) {
|
2020-03-12 21:26:36 +00:00
|
|
|
#ifdef EKCD
|
2017-10-25 00:51:00 +00:00
|
|
|
/*
|
2019-05-23 20:12:24 +00:00
|
|
|
* We can't support simultaneous unpadded block cipher
|
|
|
|
* encryption and compression because there is no guarantee the
|
|
|
|
* length of the compressed result is exactly a multiple of the
|
|
|
|
* cipher block size.
|
2017-10-25 00:51:00 +00:00
|
|
|
*/
|
2019-05-23 20:12:24 +00:00
|
|
|
if (kda->kda_encryption == KERNELDUMP_ENC_AES_256_CBC) {
|
2017-10-25 00:51:00 +00:00
|
|
|
error = EOPNOTSUPP;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2020-03-12 21:26:36 +00:00
|
|
|
#endif
|
2019-05-06 18:24:07 +00:00
|
|
|
newdi->kdcomp = kerneldumpcomp_create(newdi,
|
|
|
|
kda->kda_compression);
|
|
|
|
if (newdi->kdcomp == NULL) {
|
2017-10-25 00:51:00 +00:00
|
|
|
error = EINVAL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2012-11-01 17:01:05 +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
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
newdi->blockbuf = malloc(newdi->blocksize, M_DUMPER, M_WAITOK | M_ZERO);
|
|
|
|
|
|
|
|
/* Add the new configuration to the queue */
|
|
|
|
mtx_lock(&dumpconf_list_lk);
|
|
|
|
inserted = false;
|
|
|
|
TAILQ_FOREACH(listdi, &dumper_configs, di_next) {
|
|
|
|
if (index == 0) {
|
|
|
|
TAILQ_INSERT_BEFORE(listdi, newdi, di_next);
|
|
|
|
inserted = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
index--;
|
|
|
|
}
|
|
|
|
if (!inserted)
|
|
|
|
TAILQ_INSERT_TAIL(&dumper_configs, newdi, di_next);
|
|
|
|
mtx_unlock(&dumpconf_list_lk);
|
|
|
|
|
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);
|
2018-05-06 00:22:38 +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
|
|
|
cleanup:
|
2019-05-06 18:24:07 +00:00
|
|
|
free_single_dumper(newdi);
|
2018-05-06 00:22:38 +00:00
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
2019-10-17 18:29:44 +00:00
|
|
|
#ifdef DDB
|
|
|
|
void
|
|
|
|
dumper_ddb_insert(struct dumperinfo *newdi)
|
|
|
|
{
|
|
|
|
TAILQ_INSERT_HEAD(&dumper_configs, newdi, di_next);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
dumper_ddb_remove(struct dumperinfo *di)
|
|
|
|
{
|
|
|
|
TAILQ_REMOVE(&dumper_configs, di, di_next);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
static bool
|
|
|
|
dumper_config_match(const struct dumperinfo *di, const char *devname,
|
|
|
|
const struct diocskerneldump_arg *kda)
|
|
|
|
{
|
|
|
|
if (kda->kda_index == KDA_REMOVE_ALL)
|
|
|
|
return (true);
|
|
|
|
|
|
|
|
if (strcmp(di->di_devname, devname) != 0)
|
|
|
|
return (false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allow wildcard removal of configs matching a device on g_dev_orphan.
|
|
|
|
*/
|
|
|
|
if (kda->kda_index == KDA_REMOVE_DEV)
|
|
|
|
return (true);
|
|
|
|
|
|
|
|
if (di->kdcomp != NULL) {
|
|
|
|
if (di->kdcomp->kdc_format != kda->kda_compression)
|
|
|
|
return (false);
|
|
|
|
} else if (kda->kda_compression != KERNELDUMP_COMP_NONE)
|
|
|
|
return (false);
|
|
|
|
#ifdef EKCD
|
|
|
|
if (di->kdcrypto != NULL) {
|
|
|
|
if (di->kdcrypto->kdc_encryption != kda->kda_encryption)
|
|
|
|
return (false);
|
|
|
|
/*
|
|
|
|
* Do we care to verify keys match to delete? It seems weird
|
|
|
|
* to expect multiple fallback dump configurations on the same
|
|
|
|
* device that only differ in crypto key.
|
|
|
|
*/
|
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
if (kda->kda_encryption != KERNELDUMP_ENC_NONE)
|
|
|
|
return (false);
|
|
|
|
|
|
|
|
return (true);
|
|
|
|
}
|
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
int
|
2019-05-06 18:24:07 +00:00
|
|
|
dumper_remove(const char *devname, const struct diocskerneldump_arg *kda)
|
2018-05-06 00:22:38 +00:00
|
|
|
{
|
2019-05-06 18:24:07 +00:00
|
|
|
struct dumperinfo *di, *sdi;
|
|
|
|
bool found;
|
2018-05-06 00:22:38 +00:00
|
|
|
int error;
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
error = priv_check(curthread, PRIV_SETDUMPER);
|
2018-05-06 00:22:38 +00:00
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
/*
|
|
|
|
* Try to find a matching configuration, and kill it.
|
|
|
|
*
|
|
|
|
* NULL 'kda' indicates remove any configuration matching 'devname',
|
|
|
|
* which may remove multiple configurations in atypical configurations.
|
|
|
|
*/
|
|
|
|
found = false;
|
|
|
|
mtx_lock(&dumpconf_list_lk);
|
|
|
|
TAILQ_FOREACH_SAFE(di, &dumper_configs, di_next, sdi) {
|
|
|
|
if (dumper_config_match(di, devname, kda)) {
|
|
|
|
found = true;
|
|
|
|
TAILQ_REMOVE(&dumper_configs, di, di_next);
|
|
|
|
free_single_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
|
|
|
}
|
2019-05-06 18:24:07 +00:00
|
|
|
mtx_unlock(&dumpconf_list_lk);
|
2017-10-25 00:51:00 +00:00
|
|
|
|
2019-05-06 18:24:07 +00:00
|
|
|
/* Only produce ENOENT if a more targeted match didn't match. */
|
|
|
|
if (!found && kda->kda_index == KDA_REMOVE)
|
|
|
|
return (ENOENT);
|
2018-05-06 00:22:38 +00:00
|
|
|
return (0);
|
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
|
|
|
{
|
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
if (di->mediasize > 0 && length != 0 && (offset < di->mediaoffset ||
|
2008-01-28 19:04:07 +00:00
|
|
|
offset - di->mediaoffset + length > di->mediasize)) {
|
2018-03-08 17:04:36 +00:00
|
|
|
if (di->kdcomp != NULL && offset >= di->mediaoffset) {
|
|
|
|
printf(
|
|
|
|
"Compressed dump failed to fit in device boundaries.\n");
|
|
|
|
return (E2BIG);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
2017-10-18 15:38:05 +00:00
|
|
|
if (length % di->blocksize != 0) {
|
|
|
|
printf("Attempt to write partial block of length %ju.\n",
|
|
|
|
(uintmax_t)length);
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
if (offset % di->blocksize != 0) {
|
|
|
|
printf("Attempt to write at unaligned offset %jd.\n",
|
|
|
|
(intmax_t)offset);
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
#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;
|
2019-05-23 20:12:24 +00:00
|
|
|
case KERNELDUMP_ENC_CHACHA20:
|
|
|
|
chacha_encrypt_bytes(&kdc->kdc_chacha, buf, buf, size);
|
|
|
|
break;
|
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
|
|
|
default:
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Encrypt data and call dumper. */
|
|
|
|
static int
|
2017-10-18 15:38:05 +00:00
|
|
|
dump_encrypted_write(struct dumperinfo *di, void *virtual,
|
|
|
|
vm_offset_t physical, off_t offset, size_t 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
|
|
|
{
|
|
|
|
static uint8_t buf[KERNELDUMP_BUFFER_SIZE];
|
|
|
|
struct kerneldumpcrypto *kdc;
|
|
|
|
int error;
|
|
|
|
size_t nbytes;
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
kdc = di->kdcrypto;
|
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
|
|
|
|
|
|
|
while (length > 0) {
|
|
|
|
nbytes = MIN(length, sizeof(buf));
|
|
|
|
bcopy(virtual, buf, nbytes);
|
|
|
|
|
|
|
|
if (dump_encrypt(kdc, buf, nbytes) != 0)
|
|
|
|
return (EIO);
|
|
|
|
|
2017-10-18 15:38:05 +00:00
|
|
|
error = dump_write(di, buf, physical, offset, nbytes);
|
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
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
offset += nbytes;
|
|
|
|
virtual = (void *)((uint8_t *)virtual + nbytes);
|
|
|
|
length -= nbytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
2008-01-28 19:04:07 +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
|
|
|
|
2017-10-25 00:51:00 +00:00
|
|
|
static int
|
2018-01-08 21:27:41 +00:00
|
|
|
kerneldumpcomp_write_cb(void *base, size_t length, off_t offset, void *arg)
|
2017-10-25 00:51:00 +00:00
|
|
|
{
|
|
|
|
struct dumperinfo *di;
|
|
|
|
size_t resid, rlength;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
di = arg;
|
|
|
|
|
|
|
|
if (length % di->blocksize != 0) {
|
|
|
|
/*
|
|
|
|
* This must be the final write after flushing the compression
|
|
|
|
* stream. Write as many full blocks as possible and stash the
|
|
|
|
* residual data in the dumper's block buffer. It will be
|
|
|
|
* padded and written in dump_finish().
|
|
|
|
*/
|
|
|
|
rlength = rounddown(length, di->blocksize);
|
|
|
|
if (rlength != 0) {
|
|
|
|
error = _dump_append(di, base, 0, rlength);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
resid = length - rlength;
|
|
|
|
memmove(di->blockbuf, (uint8_t *)base + rlength, resid);
|
2020-08-27 17:36:06 +00:00
|
|
|
bzero((uint8_t *)di->blockbuf + resid, di->blocksize - resid);
|
2018-01-08 21:27:41 +00:00
|
|
|
di->kdcomp->kdc_resid = resid;
|
2017-10-25 00:51:00 +00:00
|
|
|
return (EAGAIN);
|
|
|
|
}
|
|
|
|
return (_dump_append(di, base, 0, length));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-05-06 00:22:38 +00:00
|
|
|
* Write kernel dump headers at the beginning and end of the dump extent.
|
|
|
|
* Write the kernel dump encryption key after the leading header if we were
|
|
|
|
* configured to do so.
|
2017-10-25 00:51: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
|
2018-05-06 00:22:38 +00:00
|
|
|
dump_write_headers(struct dumperinfo *di, struct kerneldumpheader *kdh)
|
2016-04-15 17:45:12 +00:00
|
|
|
{
|
2018-05-06 00:22:38 +00:00
|
|
|
#ifdef EKCD
|
|
|
|
struct kerneldumpcrypto *kdc;
|
|
|
|
#endif
|
|
|
|
void *buf, *key;
|
2017-08-18 04:07:25 +00:00
|
|
|
size_t hdrsz;
|
2018-05-06 00:22:38 +00:00
|
|
|
uint64_t extent;
|
|
|
|
uint32_t keysize;
|
|
|
|
int error;
|
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);
|
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
#ifdef EKCD
|
|
|
|
kdc = di->kdcrypto;
|
|
|
|
key = kdc->kdc_dumpkey;
|
|
|
|
keysize = kerneldumpcrypto_dumpkeysize(kdc);
|
|
|
|
#else
|
|
|
|
key = NULL;
|
|
|
|
keysize = 0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the dump device has special handling for headers, let it take care
|
|
|
|
* of writing them out.
|
|
|
|
*/
|
|
|
|
if (di->dumper_hdr != NULL)
|
|
|
|
return (di->dumper_hdr(di, kdh, key, keysize));
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
extent = dtoh64(kdh->dumpextent);
|
|
|
|
#ifdef EKCD
|
|
|
|
if (kdc != NULL) {
|
|
|
|
error = dump_write(di, kdc->kdc_dumpkey, 0,
|
|
|
|
di->mediaoffset + di->mediasize - di->blocksize - extent -
|
|
|
|
keysize, keysize);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
error = dump_write(di, buf, 0,
|
|
|
|
di->mediaoffset + di->mediasize - 2 * di->blocksize - extent -
|
|
|
|
keysize, di->blocksize);
|
|
|
|
if (error == 0)
|
|
|
|
error = dump_write(di, buf, 0, di->mediaoffset + di->mediasize -
|
|
|
|
di->blocksize, di->blocksize);
|
|
|
|
return (error);
|
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)
|
|
|
|
|
|
|
|
/*
|
2017-10-25 00:51:00 +00:00
|
|
|
* Do some preliminary setup for a kernel dump: initialize state for encryption,
|
|
|
|
* if requested, and make sure that we have enough space on the dump device.
|
|
|
|
*
|
|
|
|
* We set things up so that the dump ends before the last sector of the dump
|
|
|
|
* device, at which the trailing header is written.
|
|
|
|
*
|
|
|
|
* +-----------+------+-----+----------------------------+------+
|
|
|
|
* | | lhdr | key | ... kernel dump ... | thdr |
|
|
|
|
* +-----------+------+-----+----------------------------+------+
|
|
|
|
* 1 blk opt <------- dump extent --------> 1 blk
|
|
|
|
*
|
|
|
|
* Dumps written using dump_append() start at the beginning of the extent.
|
|
|
|
* Uncompressed dumps will use the entire extent, but compressed dumps typically
|
|
|
|
* will not. The true length of the dump is recorded in the leading and trailing
|
|
|
|
* headers once the dump has been completed.
|
2018-05-06 00:22:38 +00:00
|
|
|
*
|
|
|
|
* The dump device may provide a callback, in which case it will initialize
|
|
|
|
* dumpoff and take care of laying out the headers.
|
2017-08-18 03:52:35 +00:00
|
|
|
*/
|
|
|
|
int
|
2017-10-18 15:38:05 +00:00
|
|
|
dump_start(struct dumperinfo *di, struct kerneldumpheader *kdh)
|
2017-08-18 03:52:35 +00:00
|
|
|
{
|
2018-05-06 00:22:38 +00:00
|
|
|
uint64_t dumpextent, span;
|
2017-08-18 04:04:09 +00:00
|
|
|
uint32_t keysize;
|
2018-05-06 00:22:38 +00:00
|
|
|
int error;
|
2017-08-18 03:52:35 +00:00
|
|
|
|
2017-08-18 04:04:09 +00:00
|
|
|
#ifdef EKCD
|
2018-05-06 00:22:38 +00:00
|
|
|
error = kerneldumpcrypto_init(di->kdcrypto);
|
2017-08-18 03:52:35 +00:00
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2018-01-08 21:27:41 +00:00
|
|
|
keysize = kerneldumpcrypto_dumpkeysize(di->kdcrypto);
|
2017-08-18 04:04:09 +00:00
|
|
|
#else
|
2018-05-06 00:22:38 +00:00
|
|
|
error = 0;
|
2017-08-18 04:04:09 +00:00
|
|
|
keysize = 0;
|
|
|
|
#endif
|
2017-08-18 03:52:35 +00:00
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
if (di->dumper_start != NULL) {
|
|
|
|
error = di->dumper_start(di);
|
|
|
|
} else {
|
|
|
|
dumpextent = dtoh64(kdh->dumpextent);
|
|
|
|
span = SIZEOF_METADATA + dumpextent + 2 * di->blocksize +
|
|
|
|
keysize;
|
|
|
|
if (di->mediasize < span) {
|
|
|
|
if (di->kdcomp == NULL)
|
|
|
|
return (E2BIG);
|
|
|
|
|
2017-10-25 00:51:00 +00:00
|
|
|
/*
|
|
|
|
* We don't yet know how much space the compressed dump
|
|
|
|
* will occupy, so try to use the whole swap partition
|
|
|
|
* (minus the first 64KB) in the hope that the
|
|
|
|
* compressed dump will fit. If that doesn't turn out to
|
2018-02-13 19:28:02 +00:00
|
|
|
* be enough, the bounds checking in dump_write()
|
2017-10-25 00:51:00 +00:00
|
|
|
* will catch us and cause the dump to fail.
|
|
|
|
*/
|
2018-05-06 00:22:38 +00:00
|
|
|
dumpextent = di->mediasize - span + dumpextent;
|
2017-10-25 00:51:00 +00:00
|
|
|
kdh->dumpextent = htod64(dumpextent);
|
2018-05-06 00:22:38 +00:00
|
|
|
}
|
2017-08-18 03:52:35 +00:00
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
/*
|
|
|
|
* The offset at which to begin writing the dump.
|
|
|
|
*/
|
|
|
|
di->dumpoff = di->mediaoffset + di->mediasize - di->blocksize -
|
|
|
|
dumpextent;
|
|
|
|
}
|
|
|
|
di->origdumpoff = di->dumpoff;
|
|
|
|
return (error);
|
2017-08-18 03:52:35 +00:00
|
|
|
}
|
|
|
|
|
2017-10-25 00:51:00 +00:00
|
|
|
static int
|
|
|
|
_dump_append(struct dumperinfo *di, void *virtual, vm_offset_t physical,
|
2017-10-18 15:38:05 +00:00
|
|
|
size_t length)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
#ifdef EKCD
|
2018-01-08 21:27:41 +00:00
|
|
|
if (di->kdcrypto != NULL)
|
2017-10-18 15:38:05 +00:00
|
|
|
error = dump_encrypted_write(di, virtual, physical, di->dumpoff,
|
|
|
|
length);
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
error = dump_write(di, virtual, physical, di->dumpoff, length);
|
|
|
|
if (error == 0)
|
|
|
|
di->dumpoff += length;
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
2017-10-25 00:51:00 +00:00
|
|
|
/*
|
|
|
|
* Write to the dump device starting at dumpoff. When compression is enabled,
|
|
|
|
* writes to the device will be performed using a callback that gets invoked
|
|
|
|
* when the compression stream's output buffer is full.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
dump_append(struct dumperinfo *di, void *virtual, vm_offset_t physical,
|
|
|
|
size_t length)
|
|
|
|
{
|
|
|
|
void *buf;
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
if (di->kdcomp != NULL) {
|
|
|
|
/* Bounce through a buffer to avoid CRC errors. */
|
2017-10-25 00:51:00 +00:00
|
|
|
if (length > di->maxiosize)
|
|
|
|
return (EINVAL);
|
2018-01-08 21:27:41 +00:00
|
|
|
buf = di->kdcomp->kdc_buf;
|
2017-10-25 00:51:00 +00:00
|
|
|
memmove(buf, virtual, length);
|
2018-01-08 21:27:41 +00:00
|
|
|
return (compressor_write(di->kdcomp->kdc_stream, buf, length));
|
2017-10-25 00:51:00 +00:00
|
|
|
}
|
|
|
|
return (_dump_append(di, virtual, physical, length));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write to the dump device at the specified offset.
|
|
|
|
*/
|
2017-10-18 15:38:05 +00:00
|
|
|
int
|
|
|
|
dump_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));
|
|
|
|
}
|
|
|
|
|
2017-08-18 03:52:35 +00:00
|
|
|
/*
|
2017-10-25 00:51:00 +00:00
|
|
|
* Perform kernel dump finalization: flush the compression stream, if necessary,
|
|
|
|
* write the leading and trailing kernel dump headers now that we know the true
|
|
|
|
* length of the dump, and optionally write the encryption key following the
|
|
|
|
* leading header.
|
2017-08-18 03:52:35 +00:00
|
|
|
*/
|
|
|
|
int
|
2017-10-18 15:38:05 +00:00
|
|
|
dump_finish(struct dumperinfo *di, struct kerneldumpheader *kdh)
|
2017-08-18 03:52:35 +00:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
if (di->kdcomp != NULL) {
|
|
|
|
error = compressor_flush(di->kdcomp->kdc_stream);
|
2017-10-25 00:51:00 +00:00
|
|
|
if (error == EAGAIN) {
|
|
|
|
/* We have residual data in di->blockbuf. */
|
2020-08-27 17:36:06 +00:00
|
|
|
error = _dump_append(di, di->blockbuf, 0, di->blocksize);
|
|
|
|
if (error == 0)
|
|
|
|
/* Compensate for _dump_append()'s adjustment. */
|
|
|
|
di->dumpoff -= di->blocksize - di->kdcomp->kdc_resid;
|
2018-01-08 21:27:41 +00:00
|
|
|
di->kdcomp->kdc_resid = 0;
|
2017-10-25 00:51:00 +00:00
|
|
|
}
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We now know the size of the compressed dump, so update the
|
|
|
|
* header accordingly and recompute parity.
|
|
|
|
*/
|
2018-05-06 00:22:38 +00:00
|
|
|
kdh->dumplength = htod64(di->dumpoff - di->origdumpoff);
|
2017-10-25 00:51:00 +00:00
|
|
|
kdh->parity = 0;
|
|
|
|
kdh->parity = kerneldump_parity(kdh);
|
|
|
|
|
2018-01-08 21:27:41 +00:00
|
|
|
compressor_reset(di->kdcomp->kdc_stream);
|
2017-10-25 00:51:00 +00:00
|
|
|
}
|
|
|
|
|
2018-05-06 00:22:38 +00:00
|
|
|
error = dump_write_headers(di, kdh);
|
2017-08-18 03:52:35 +00:00
|
|
|
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,
|
2020-02-23 03:32:16 +00:00
|
|
|
const 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);
|
2017-10-25 00:51:00 +00:00
|
|
|
kdh->dumpextent = kdh->dumplength;
|
2008-10-01 22:08:53 +00:00
|
|
|
kdh->dumptime = htod64(time_second);
|
2017-08-18 04:04:09 +00:00
|
|
|
#ifdef EKCD
|
2018-01-08 21:27:41 +00:00
|
|
|
kdh->dumpkeysize = htod32(kerneldumpcrypto_dumpkeysize(di->kdcrypto));
|
2017-08-18 04:04:09 +00:00
|
|
|
#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));
|
2018-01-08 21:27:41 +00:00
|
|
|
if (di->kdcomp != NULL)
|
2018-02-13 19:28:02 +00:00
|
|
|
kdh->compression = di->kdcomp->kdc_format;
|
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
|