From owner-svn-src-all@freebsd.org Sat Dec 10 20:53:53 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 050D2C71B2A; Sat, 10 Dec 2016 20:53:53 +0000 (UTC) (envelope-from def@FreeBSD.org) Received: from troz.pl (troz.pl [37.187.125.115]) by mx1.freebsd.org (Postfix) with ESMTP id AF75F12D9; Sat, 10 Dec 2016 20:53:52 +0000 (UTC) (envelope-from def@FreeBSD.org) Received: from [192.168.0.2] (unknown [185.118.250.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by troz.pl (Postfix) with ESMTPSA id 77D42B54; Sat, 10 Dec 2016 21:53:51 +0100 (CET) Subject: Re: svn commit: r309818 - in head: etc/defaults etc/rc.d sbin sbin/decryptcore sbin/dumpon sbin/savecore share/man/man5 sys/amd64/amd64 sys/arm/arm sys/arm64/arm64 sys/conf sys/ddb sys/dev/null sys/geo... To: Justin Hibbits References: <201612101620.uBAGKdUg033773@repo.freebsd.org> <043C7408-A0FA-4316-B24B-3A181146FE20@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Konrad Witaszczyk Message-ID: <56f24e51-140c-5e30-08df-9ffa0bdf73bb@FreeBSD.org> Date: Sat, 10 Dec 2016 21:53:43 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <043C7408-A0FA-4316-B24B-3A181146FE20@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pcBACHb1tJsCBK53djlXx7bFX6AgLnw9n" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 20:53:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pcBACHb1tJsCBK53djlXx7bFX6AgLnw9n Content-Type: multipart/mixed; boundary="Sv7Dmm0KL9WeHtg4HHVPQFfDn0REoR9hj"; protected-headers="v1" From: Konrad Witaszczyk To: Justin Hibbits Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: <56f24e51-140c-5e30-08df-9ffa0bdf73bb@FreeBSD.org> Subject: Re: svn commit: r309818 - in head: etc/defaults etc/rc.d sbin sbin/decryptcore sbin/dumpon sbin/savecore share/man/man5 sys/amd64/amd64 sys/arm/arm sys/arm64/arm64 sys/conf sys/ddb sys/dev/null sys/geo... References: <201612101620.uBAGKdUg033773@repo.freebsd.org> <043C7408-A0FA-4316-B24B-3A181146FE20@gmail.com> In-Reply-To: <043C7408-A0FA-4316-B24B-3A181146FE20@gmail.com> --Sv7Dmm0KL9WeHtg4HHVPQFfDn0REoR9hj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/10/2016 20:20, Justin Hibbits wrote: > On Dec 10, 2016, at 10:20 AM, Konrad Witaszczyk wrote: >> Author: def >> Date: Sat Dec 10 16:20:39 2016 >> New Revision: 309818 >> URL: https://svnweb.freebsd.org/changeset/base/309818 >> >> Log: >> 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 du= mp >> configuration in the diocskerneldump_arg structure to the kernel. >> The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FR= EEBSD11 >> 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 s= upported >> but EKCD was designed to implement support for other algorithms in th= e future. >> The public key is chosen using the -k flag. The dumpon rc(8) script c= an do this >> automatically during startup using the dumppubkey rc.conf(5) variable= =2E Once >> the >> keys are calculated dumpon sends them to the kernel via DIOCSKERNELDU= MP 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 tim= e the >> kernel tries to write a crash dump to the dump device, the IV is repl= aced by >> a SHA-256 hash of the previous value. This is intended to make a poss= ible >> differential cryptanalysis harder since it is possible to write multi= ple crash >> dumps without reboot by repeating the following commands: >> # sysctl debug.kdb.enter=3D1 >> db> call doadump(0) >> db> continue >> # savecore >> >> A kernel dump key consists of an algorithm identifier, an IV and an e= ncrypted >> 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 s= ize. >> 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 th= at the >> kernel dump key is placed after the first header on the dump device a= nd the >> core >> dump is encrypted. >> >> Separate functions were implemented to write the kernel dump header a= nd the >> kernel dump key as they need to be unencrypted. The dump_write functi= on >> encrypts >> data if the kernel was compiled with the EKCD option. Encrypted kerne= l >> 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 text= dumps >> don't >> contain sensitive data by design as a user decides what information s= hould 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 par= tially >> decrypted core dump. >> >> Description on how to encrypt crash dumps was added to the decryptcor= e(8), >> dumpon(8), rc.conf(5) and savecore(8) manual pages. >> >> EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 usi= ng QEMU. >> The feature still has to be tested on arm and arm64 as it wasn't poss= ible 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 >> >> Added: >> head/sbin/decryptcore/ >> head/sbin/decryptcore/Makefile (contents, props changed) >> head/sbin/decryptcore/decryptcore.8 (contents, props changed) >> head/sbin/decryptcore/decryptcore.c (contents, props changed) >> Modified: >> head/etc/defaults/rc.conf >> head/etc/rc.d/dumpon >> head/sbin/Makefile >> head/sbin/dumpon/Makefile >> head/sbin/dumpon/dumpon.8 >> head/sbin/dumpon/dumpon.c >> head/sbin/savecore/savecore.8 >> head/sbin/savecore/savecore.c >> head/share/man/man5/rc.conf.5 >> head/sys/amd64/amd64/minidump_machdep.c >> head/sys/arm/arm/minidump_machdep.c >> head/sys/arm64/arm64/minidump_machdep.c >> head/sys/conf/NOTES >> head/sys/conf/files >> head/sys/conf/options >> head/sys/ddb/db_textdump.c >> head/sys/dev/null/null.c >> head/sys/geom/geom_dev.c >> head/sys/i386/i386/minidump_machdep.c >> head/sys/kern/kern_dump.c >> head/sys/kern/kern_shutdown.c >> head/sys/mips/mips/minidump_machdep.c >> head/sys/sparc64/sparc64/dump_machdep.c >> head/sys/sys/conf.h >> head/sys/sys/disk.h >> head/sys/sys/kerneldump.h > > Nice! Any reason you left out PowerPC from this list though? The architectures that I listed implement separate minidump functions in = their MD code. I had to change them to implement EKCD. ppc and pc98 are not the= case and we don't have minidumps in riscv yet. It means that EKCD should also = work on ppc. Of course all architectures supported by FreeBSD should be verified. Howe= ver it is mandatory to test all changes in MD code. --Sv7Dmm0KL9WeHtg4HHVPQFfDn0REoR9hj-- --pcBACHb1tJsCBK53djlXx7bFX6AgLnw9n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE/bUwFm9Qs8vtm2934cEiWwsmpPAFAlhMa1dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE QjUzMDE2NkY1MEIzQ0JFRDlCNkY3N0UxQzEyMjVCMEIyNkE0RjAACgkQ4cEiWwsm pPDT/hAAi1OCLs5w/uEoTE3MnPYhR97vEL7ylWK+GjXib0SsX7GFqwJDdKz8WhnB HOyih74jXpCSywewvASjAWO2VGrZjLhaLZySyKODoj1lt4QUuXlVkX6Pf75/URfu poEWKUArv3EzTO229zBFBrwB+YQh9hNeD76ssSdjREap3AHgrMuNqjO0l4tfQqG2 fCE7Xa7+YGHVHABoeLkfD7769+Js+cq7v32dHhC+LP+VXbhLkK0bFK9Z+U33p/n5 WdWR5Ly2Fs+B/v8/WTZUCwwac6q+ogs//gIqAfatXJ65a6a6ed1APNQk9qnsdLpi ByUayad7JDm/4x4YWfxJ9zvYNZhRUSuKs2BDIgt2n9NULLQd3ILj0xT33NfANBjQ ZNDJYcoZWk+cv2DvxD8nPCcxVwdeTgMopZtQ91+Gp6IrL2CXTNjygODUDllegHAn Jmf64f0yCd9m/02og//W6GveT5IHV44WdeA99b5vzJay+ZAHcsd9b0YEllrBXW+k rwXBcEYaBl0I0vHu+bMN/Ga/bmOJLCVCD4qQR2LwNJtvryT+7JFb8yyxfXbuEet/ FjwdidF35VAZD9xvK6b4TYhw+xjan6sIY4TrRd7VKFPmgjMy16ILt1Er3kZo0xLc TCyMjEgA38NQrrd8anwkw+5Sp/OkxIjEMJzJ0U3cAgVY1jAL8Ds= =krDr -----END PGP SIGNATURE----- --pcBACHb1tJsCBK53djlXx7bFX6AgLnw9n--