Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
- Perform final decryption and write decrypted data in case of non-block aligned
input data;
- Use strlcpy(3) instead of strncpy(3) to verify if paths aren't too long;
- Check errno after calling unlink(2) instead of calling stat(2) in order to
verify if a decrypted core was created by a child process;
- Free dumpkey.
Reported by: Coverity, cem, pfg
Suggested by: cem
CID: 1366936, 1366942, 1366951, 1366952
Approved by: pjd (mentor)
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
A premature optimization lead to caching a native-sector sized memory
allocation. If the program examined a 512 byte sector disk, then a 4096
byte sector disk, the program would overrun the cached 512 byte buffer.
Just remove the optimization to fix the bug. This was introduced with the 4Kn
dump support in r298076.
Reported by: markj
Reviewed by: markj, rpokala
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8162
Also, call endfsent after calling getfsent (i.e. when not explicitly called
with a swap device) for code cleanliness
CID: 1354785
Differential Revision: https://reviews.freebsd.org/D6014
X-MFC with: r298076
Reported by: Coverity
Reviewed by: cem
Sponsored by: EMC / Isilon Storage Division
(And 4Kn minidump support, but only for amd64.)
Make sure all I/O to the dump device is of the native sector size. To
that end, we keep a native sector sized buffer associated with dump
devices (di->blockbuf) and use it to pad smaller objects as needed (e.g.
kerneldumpheader).
Add dump_write_pad() as a convenience API to dump smaller objects with
zero padding. (Rather than pull in NPM leftpad, we wrote our own.)
Savecore(1) has been updated to deal with these dumps. The format for
512-byte sector dumps should remain backwards compatible.
Minidumps for other architectures are left as an exercise for the
reader.
PR: 194279
Submitted by: ambrisko@
Reviewed by: cem (earlier version), rpokala
Tested by: rpokala (4Kn/512 except 512 fulldump), cem (512 fulldump)
Relnotes: yes
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5848
Make savecore(8) more suitable for init-time scripts; be quiet by default.
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3229
This is a follow-up to r289845, which only fixed one occurence of CID
1009429.
Coverity CID: 1009429
Reviewed by: markj
MFC after: 2 weeks
X-MFC-With: r289845
Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D4096
last one. To make it easier to find the last one create symlinks with 'last'
suffix that will point to the files of the last coredump, eg.:
info.last -> info.5
textdump.tar.last.gz -> textdump.tar.5.gz
Reviewed by: avg
Obtained from: WHEEL Systems
provide dump directory. Eliminate this redundant argument. This changes
the usage, but the only risk here is that a warning will be printed
about directory given as device.
- Update usage of -C option.
- When clearing dump header from the given device there is also no need to
provide dump directory, although additional arguments for -c were not
documented.
- Document that -v can be used with -c and that list of devices can be given.
Obtained from: WHEEL Systems
rather than the memcmp() which is used for regular dumps: the
textdump string is one character shorter, so we need to stop
comparing at the end of the string.
Use independent version checking logic for architecture-specific
version number vs. textdump version number, as the version sequences
may (someday) differ.
Run into by: rrs
at LOG_WARNING by default; instead, consider it something to be printed
to the tty when 'verbose' mode is set. This avoids printing out extra
lines at every boot on a system with crash dumps enabled, but that has
not yet had to generate a crashdump.
MFC after: 1 week
the stack to the heap to work around a problem on ia64. Now, roughly
16 months and two compiler updates later, it isn't an issue anymore
in the sense that putting a 1M buffer on the stack just works and we
don't actually need to work around anything anymore.
However, since there's no advantage or need to put the buffer on the
stack (again), this change merely removes the XXX comment describing
that there's an explicit reason for the heap allocation. Hence, this
change is a functional no-op.
PR: ia64/38677
The immediate purpose for this option is to use it in rc.d so that we
can make savecore behavior conditional.
Tremendous assistance with ideas and sanity checking provided by tjr
and b@etek.chalmers.se.
- reimplement -z
- use syslog()
- improve consistancy of messages
- allow -f to recover cleared dumps
- return bufsize to 1024 * 1024
- return the ability to write sparse files
- update man page
- fix minfree to require 2k for info file instead of the kernel size
- include Berkeley copyright too due to amount of old code copied
Submitted by: Chad David <davidc@acns.ab.ca>
