From owner-freebsd-questions@freebsd.org Sun Aug 5 15:25:07 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0DB31055858 for ; Sun, 5 Aug 2018 15:25:06 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9F392E46 for ; Sun, 5 Aug 2018 15:25:06 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.64.203]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.167]) with ESMTPA (Nemesis) id 0Lmyqm-1gR9pc0sma-00h6Vh; Sun, 05 Aug 2018 17:25:04 +0200 Date: Sun, 5 Aug 2018 17:25:03 +0200 From: Polytropon To: thor Cc: freebsd-questions@freebsd.org Subject: Re: Erase memory on shutdown Message-Id: <20180805172503.e2479108.freebsd@edvax.de> In-Reply-To: References: Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:s4Pw1XwWiLog7Hr4CIBu6Nz4z9EfaeGUK9NUFxq9fAez0MEqBI+ 7kyEFESpvzRyeB5hU9B0nNOHZUCCScoOOXYReB4PxTyIqNV352knKP1hSZi9C6Cg2ZTQ1yA wd2WEMTn2Ct+4PFdmy1KEDWlepVMNg1cM6mJFCcHgsC+AqN1d0vBqH8lc2NGGZKFthYJM1o o3xuzqdgZDkkLfq/YMmMg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ty9yPiRORn4=:q5E2zMWZAgb24gPltwYn2V 1S9X6U5r6jNP8u/1caO4HwTpcbWIFAu8kKnKj2pxOltkn0p53UNSdBpkJyXpm1G2K4bJcbG0Z DBYVKrSWEOSajVq2NOP8l+lxknLrwA9YzbYlXQDewREW10X6nZcPtPSrRb4ZHAAJBaPOy1y4w Dzc1vvV/N6bciW+SLAeA8/Z4WespUIxf8TkkDAM2i24Lkgz/h55jGkBjal5mlpCe5q7WjdrlG UddDcxuXXtsTGf6j3Gpbm7Z2cDICkgGJABNUiFfkZRNBHqOQnoap3OVf4ga6wmjqtD+PZKk6S JGK0e8AcKDSfru0ZMKkL/ATn/YRX/uVkj7Bok5RCwF1I+azYG+pNnwPrVNXFeqMjyb+f4pU/n 8Wan03MYBsMH44eSwcTy0TDOIWn0QXpQAL5TRXPsELWGQe0DN0sMR7FVrskzPiwRjxZtyGtw2 axfrJ86IoK5mKelA2AIrIJP2yc/qAkL6DGt9CvennkF7o4c41W1SvSu8WkDxpRc5ufSlZ2HVb hHxmpxb8jWQ2g2sgy1tZpZ5iPAcQFenT9PJ5AKfTCx4HYd5mjOg7ZLsq0LLFQqm6EFV3JDJHj 6bu6r9YzqRDVHtK72PgrEP/fdL1wsYC/mao6mNyu13fjpV6Xl6bpFYhocgy2P8vmMxWsoPYtl wXPgqODCtFHEzR9Qf27cQv/43L+3N9az7vU49LQuVXl2in0QehWQ4dienIzLxgOsx69sQKlgM V5cBe/UoPs8FJoQd X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 15:25:07 -0000 On Sun, 5 Aug 2018 22:24:16 +0800, thor wrote: > Just one paranoid question: How to cause FreeBSD to zero all RAM during > shutdown? This would imply that the kernel would finally have to overwrite itself. How can control over zeroing memory be maintained when the control program itself has been overwritten? That would be the result of the "all" in your requirement. Sure, you could add some code to the final shutdown routines to zero the RAM, which is possible, but not trivial: You need a non-optimized call to memset() using a custom function pointer. static void *(* const volatile memset_ptr)(void *, int, size_t) = memset; static void secure_memzero(void *p, size_t len) { (memset_ptr)(p, 0, len); } void *ram = 0x0; /* RAM start address */ size_t amount = 17179869184UL; /* 16 GB RAM */ secure_menzero(ram, amount); /* ouch */ If you add something like this to the kernel, and make sure your compiler isn't too clever (as to optimize it into a NOP), you're going to crash the whole system without actually being sure that at least a part of the RAM has been zeroed. And even then it might not work as intended. See: http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html http://www.daemonology.net/blog/2014-09-05-erratum.html Keep in mind: You're declaring war on intended security mechanisms if you try to do this. :-) However, this is not guaranteed (!) to work, so you cannot be safe. And you must do it from the kernel. You cannot use (a privileged) program like dd to flush /dev/mem and /dev/kmem with /dev/zero output. Your best bet is to assume that RAM will be zeroed as soon as the power-off routine as been completed - no refresh, no content. Not perfectly secure, though... :-) RAM usually isn't zeroed, but marked as "not in use" so it can be overwritten. Address randomization makes it hard to protect where something will appear in RAM, and access to RAM requires certain privileges on a system. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...