From nobody Fri Jan 14 18:13:03 2022 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6AF8F1947208 for ; Fri, 14 Jan 2022 18:13:09 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb8YJ3ztNz4rYb for ; Fri, 14 Jan 2022 18:13:08 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4Jb8YH16MHzF4fw for ; Fri, 14 Jan 2022 10:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1642183987; bh=eRqV5aOJCW7P7W90JWMuHsHNT8CV7h/+YqgwceXDUZ0=; h=Date:From:To:Subject:In-Reply-To:References:From; b=h2BBhZam9/VIr3DQ96acsfX9GiNmKJoKLm+LymPBj5bc6eovRhzOLLYAKxjcQpL7L HolINDWiV//PfxOdDa5icSW9VcKlWhMla6m1Xaby8YyvfbI++HfkEevN+yl5zqS1qr IuRpUAzVelogGh8j9dIqNxJdzMRAO8VAznW9QbHg= X-Riseup-User-ID: CEE2902866892D13B7AB36505C81AA973C7F0101B9648AE86CE0A6151D0B3064 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4Jb8YG40gkz1xmv for ; Fri, 14 Jan 2022 10:13:06 -0800 (PST) Date: Fri, 14 Jan 2022 19:13:03 +0100 From: Ralf Mardorf To: questions@freebsd.org Subject: Re: zero filling a storage device (was: dd and mbr) Message-ID: <20220114191303.171f1cad@archlinux> In-Reply-To: <523b6b6d-b17c-e632-a36a-a8c26ad61798@qeng-ho.org> References: <77680665-7ddb-23c5-e866-05d112339b60@holgerdanske.com> <20220114023002.GP61872@eureka.lemis.com> <523b6b6d-b17c-e632-a36a-a8c26ad61798@qeng-ho.org> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jb8YJ3ztNz4rYb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=h2BBhZam; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of ralf-mardorf@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=ralf-mardorf@riseup.net X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[riseup.net:+]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[questions]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from] X-ThisMailContainsUnwantedMimeParts: N On Fri, 14 Jan 2022 17:14:18 +0000, Arthur Chance wrote: >On 14/01/2022 15:32, Christian Weisgerber wrote: >> "Kevin P. Neal": >> >>> Are we certain that an SSD won't at least track that there is >>> nothing written to a logical block and therefore it must be all >>> zeros? I'm not 100% that an SSD will always keep a logical block >>> assigned to a physical block. And I'm not 100% certain that an SSD >>> won't notice that all zeros are being written to a block and just >>> optimize out the write. >> >> It's tempting to speculate that an SSD could treat an all-zeros >> block write effectively like a TRIM. >> >> I'll note that there are SSDs that compress the data written to >> them. (Compression in storage devices isn't new. Terry Welch's >> 1984 paper, where he presented the LZW compression algorithm, already >> talks about this.) >> > >May I suggest "man trim"? (From 12.1 onwards.) *?* Nothing on the operating system side of the SSD's controller (and its firmware) has got direct access to what's under the hood of the SSD. Due to wear leveling a SSD much likely keeps a lot of not really erased sensitive data. This data is not accessible/restoreable without replacing the firmware by a forensic tool or by an unhappy coincidence, but replacing firmware is way more likely, than a high-tech lab to restore secret data and even an unhappy coincidence isn't far too unlikely.