From owner-freebsd-questions@freebsd.org Sun Aug 5 15:42:25 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 628A010560F7 for ; Sun, 5 Aug 2018 15:42:25 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB53C9399C for ; Sun, 5 Aug 2018 15:42:24 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: by mail-it0-x243.google.com with SMTP id v71-v6so14868761itb.3 for ; Sun, 05 Aug 2018 08:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-transfer-encoding; bh=K16jKAlxcN9FOoeTZj/FSa1ImFdP++lENMQqiUyuWdA=; b=p2d1nTFrsxl9+z9GePpviWFNLi8/PjxKEivwSmLIz/mIdv86UHRrNx2c8C24VcG7DJ IvkKm/Clr1wnWWXdILCnn+i2ZH4gIEZiMg4R+dIdMkWNp7UJAyv4UhbeyuTNbee0wfiX Qff0NkJKfZ4xqPCmRENhLh6+CZXlNIA6cQ8EuJxy0it8hdjZBviCgLoaqFwmNDur6h9N jatRO99Q4954tuswsi5BLf/J304EE1WNR3vjLd5jmziOYRIeZt8bBX4lKLADZWmVuwbN xlJfzJ5WUxTSkES16XSDv/ZiBeRZG15unnDKz0uy/CGRSelNjYHcpNr6sIuBDtuBPA3P huJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-transfer-encoding; bh=K16jKAlxcN9FOoeTZj/FSa1ImFdP++lENMQqiUyuWdA=; b=Pabv6VaQskw6HBo4aBbwnmVeqSMWSChQWxHc22tSEeBQhN8cUdjtjhOAm9APwaP7Jp nMMcI7Ms9+5XlzwfBP2p0SbMRP5EGbWMKrlS9BuW6ZwWCuEulMCRE2tPidjYTIL190pK aztV6eJjLPlV1shye7dFxLrUggQ8PGF6qpuRX6a4V3/K494pSUFdaTHmK1Bl2zVxM+mw Y5CRyy7LHQl0XgSiyi7AM7a5LdAO3dGHn7aKwAj8CJVaaKUAF8xUk66N2LRH0uQjIwTv g7LtkV5Kj7Uo4YVRXA1azw+18aH472ks9+0rNX4xk/2XxfuIja4hzPfv3/Wx2QFNoB8z t1tQ== X-Gm-Message-State: AOUpUlEuYIjURQyIoa6QYENiRCr3ttVfpxO8L8skrtpfsmwS2oi/1P1N tp3LgT+8cAvrMRCnJkWVhSdJKOLV X-Google-Smtp-Source: AAOMgpey0KVCjrHvXMUs009auIW7BG2yvhcJBgm/0sHDkaKfNGBkHjPG9G38tikUY0QVpeVe8drYLw== X-Received: by 2002:a24:eb0e:: with SMTP id h14-v6mr13568477itj.69.1533483744113; Sun, 05 Aug 2018 08:42:24 -0700 (PDT) Received: from localhost.localdomain (50-243-4-3-static.hfc.comcastbusiness.net. [50.243.4.3]) by smtp.googlemail.com with ESMTPSA id j78-v6sm2692967itj.44.2018.08.05.08.42.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 08:42:23 -0700 (PDT) Message-ID: <5B671AF5.7080701@gmail.com> Date: Sun, 05 Aug 2018 09:42:45 -0600 From: JD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Erase memory on shutdown References: <20180805172503.e2479108.freebsd@edvax.de> In-Reply-To: <20180805172503.e2479108.freebsd@edvax.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:42:25 -0000 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. I do not mean to piss off anyone, just wondering about this myself. My question is: currently, if the machine is shut down, (i.e. powered off), does ram keep it's content? If yes, how? for how long? Is it static ram, or does the battery provide the power for the ram to remain refreshed? Cheers, JD