From owner-freebsd-questions@freebsd.org Sun Aug 5 16:02:16 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 E59EF105676A for ; Sun, 5 Aug 2018 16:02:15 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 61AFA94213 for ; Sun, 5 Aug 2018 16:02:15 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.64.203]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.183]) with ESMTPA (Nemesis) id 0LfznH-1gIf2l1oGR-00pe6B; Sun, 05 Aug 2018 18:02:12 +0200 Date: Sun, 5 Aug 2018 18:02:12 +0200 From: Polytropon To: JD Cc: freebsd-questions@freebsd.org Subject: Re: Erase memory on shutdown Message-Id: <20180805180212.1cbfd1dc.freebsd@edvax.de> In-Reply-To: <5B671AF5.7080701@gmail.com> References: <20180805172503.e2479108.freebsd@edvax.de> <5B671AF5.7080701@gmail.com> 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:Z4g452ldpWJ07QwEYdQPrEnqe45HWpz8QUzqmgzD3QM55f34Rtz ekjfvWJ7vS4qOK31j/aguyH5ydGrrPdHnylwssb0KC5/dTQkIeTpPvaC84KzOfomLT9Glws lBYqQURumcMuFYO9Uqm3sh2HfkwZc8HFM3bhP8ZX2b9cJVPnamZY/sDP4/i5kRIzvjVS/6h 4oU21YfIyjHJILbUX2MTA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Yfn+rAkxtEw=:nXEmNCLQ0Nxzcs4RGEHfe4 0V+CFXHC4hMuDloUyEy+pbSPAVNay94WeVICOc7VVFkHoOHCJgM1Y01OUNqzhNUc3enzy6irh Bl3eLXwaV7TAlSxN/EwwMxeVbI7J0il4zHrJidClCgSlVdAyfQtLOwuVkIM0jCm/0m9bthtOb n5kAk1OqZlmbWlmjHX5M38ZkxyH3gkXT9BRY1N+i1kviDRfkS/Vp6fscFSAcIzijydiFAqGr9 IAbqp0EODwS98/oBcE82wTl7KubaTKNPQkiyYXLgWDO/Eyky5uoWW7dpmFyUPti+6r2ONFsrU 1NK4GwYcjLmh0dIUgkdTAOPMDyEkA/uvxLxGcyX5dqIyg00IFLQRPk9IBBTJdHlUdU+HEzEXB QP9jPmwOu7X/U0WslDq7OZDIdohKhMBVrA58Pz8tXyDPqs13b62Y0xqdu8tK+uvh/6wDBob8J 6WNo4U3k58cZqccZ8OQ5U//BLPSi1JnO0PEGk0i/F0C9wVViDldE/JqUIVl4vCjxAKSwhfI1Y jyKTUxn5MwpbhqcwzbIC1/WnqKuMFBsmT2W0cU/33zIvdysk5Vg8d2pPXfFtCsYefTE4OR5M4 RqqmjPScrcGQVjfzWU1ARoMbNGgclfh3GbH+5yuludYQzsI+6BfDFEz0JYEtu7uvsC5X8kPlT PGiZ+LDRtkoy9/qtKbp1odYvx0miNH29K/cZBj0UNx09PfhW2fA34nJE8l4hOTegxBzjTOVaf RDtkfZn/29y5E4lM 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 16:02:16 -0000 On Sun, 05 Aug 2018 09:42:45 -0600, JD wrote: > > > On 08/05/2018 09:25 AM, Polytropon wrote: > > 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. > > > > > Just for the heck of it: > allocate from contiguous freemem for the program in question, > load the program, > transfer control to the program which should passed > it starting addy, and size, and total mem size. > Such a program would work, assuming it is written to watch > out for it's addy space, and not overwrite itself. It's not about the program itself. Assume it is run as a user process (by root, for example). It should not overwrite itself, it also should not overwrite the kernel and other system facilities in memory whose removal could cause a kernel crash before the zeroing is complete. That's why I suggested it _could_ be introduced as new code into the kernel, to be performed at the latest stage of system shutdown. > My question is: currently, if the machine is shut down, > (i.e. powered off), does ram keep it's content? Theory: No. Practice: Yes. > If yes, > > how? Capacitive effects? > for how long? Until capacity is drained out. > Is it static ram, or does the battery provide the power > for the ram to remain refreshed? Usually not. During normal operations, RAM is refreshed periodically. This is the 'D' in DRAM - dynamic. The most prominent case of static RAM is core memory. It keeps it content (after magnetization) until the memory is read again. So if you found a core memory matrix with a program in it from 1970, the content could still be in there... :-) So you see, even static RAM needs a refresh (after a read), usually with the values read. There are "suspend to RAM" mechanisms where the RAM is buffered from the PSU (or in case of laptops: from battery) until the power runs out. This means that the computer technically isn't off - it's just that the CPU isn't running, only the controllers for the memory control are performing their normal work. There are also buffer batteries for "critical RAM" that can keep the RAM intact during power outages. But I don't know if they also buffer CPU registers which would be neccessary to resume operations when the power comes back. Also see: https://en.wikipedia.org/wiki/Cold_boot_attack -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...