X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7151D385480B
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=pdinc.us
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jpyeron AT pdinc DOT us
DKIM-Filter: OpenDKIM Filter v2.11.0 mail2.pdinc.us 0BT2fLuj031021
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pdinc.us; s=default;
 t=1609209681; bh=HGXD8QRJ9qrghLqq1D4PursgdPfuXJP0K3oi9HUfbiY=;
 h=From:To:References:In-Reply-To:Subject:Date:From;
 b=Aoh9ZRsA3nCqtH7Z0Slh8VRfUoHkqLMx9QoFCz8UbaVgnvFLGMJK0nRXRAmtf9X1W
 9KShcNg/yiF6nm7eW6y9FoaU5Pdt+calqphPJE9LC/C85/LG3RJ7XtQchBHG6c5sJr
 HO4KF17dykk0q8VA/9IdFMj3YojpijpLiiSUNoqVIAkkE8JlNyu6ggdeI0lHaN/6QZ
 TH17TW9HUXpH+ODimqSjPTV+clkOVZqZX4vU3DkkWnPnawm+HyvBCNfdgjRyoNs73q
 pKh2eYXhFSpgUjzGnhTbZwpRcThEPOwurD3Q8OMfcDhNZjOCDBorcIzr8EMdudTvnU
 xb/e/cD1XrnJQ==
From: "Jason Pyeron" <jpyeron AT pdinc DOT us>
To: <cygwin AT cygwin DOT com>
References: <DB7PR01MB5193A18F1D947ED4C276CD25D5980 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <1d1801d64677$bea56050$3bf020f0$@pdinc.us>
 <DB7PR01MB5193CC1C7630FB13B81B9DBAD5980 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <60bf1507-4edb-a03f-ec14-07e1ab7f0d94 AT cs DOT umass DOT edu>
 <DB7PR01MB519396195ADB3E3E1217B22BD5940 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>,
 <1b13fde4-0834-cd8b-0673-c2b14bbaa372 AT SystematicSw DOT ab DOT ca>
 <DB7PR01MB5193BA73A9E8E08912AEBADED5D80 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
In-Reply-To: <DB7PR01MB5193BA73A9E8E08912AEBADED5D80@DB7PR01MB5193.eurprd01.prod.exchangelabs.com>
Subject: RE: [cygwin] DD bug fails to wipe last 48 sectors of a disk
Date: Mon, 28 Dec 2020 21:41:31 -0500
Message-ID: <121001d6dd8c$1dc8b0e0$595a12a0$@pdinc.us>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQGscau3vmYRj+s+e2PTQd4MF23JZQNbIR/1ATPrTR8BvLqaegH1Mf0MAb1HszEA12M7fKoLfvQw
Content-Language: en-us
X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, SPF_HELO_PASS,
 SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

> -----Original Message-----
> From: Hashim Aziz via Cygwin
> Sent: Monday, December 28, 2020 7:46 PM
> 
>> From: Cygwin <cygwin-bounces AT cygwin DOT com> on behalf of Brian Inglis
>> <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
>> Sent: 23 June 2020 8:33 PM
>> To: cygwin AT cygwin DOT com <cygwin AT cygwin DOT com>
>> Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk
>> 
>> I don't have the facilities to test, and there appear to be *NO* Windows
>> documentation details on error condition handling, but my suspicion is that Unix
>> reads and writes fail only *AFTER* reading or writing at the end of the device,
>> but Windows reads and writes extents may be checked and failed *BEFORE* reading
>> or writing any data near the end of the device.
>> If the actual Windows error code returned is generic, Cygwin would need to
>> pre-check the device size as Windows does, and reduce read and write sizes to
>> the allowed maximum at the end of the device.
> 
> That's very helpful, thank you. Do you know if any more work has been done to attempt to
> fix this bug, and whether it's likely to be fixed anytime soon? It's crazy that such a
> commonly used command leaves so much data unwiped unbeknown to so many users, it's a very
> serious security hole and the sooner it can be fixed the better.

Have you tried iflag=fullblock ? This causes special handling.

> Sent: Monday, December 28, 2020 7:25 PM
> To: Jason Pyeron 
> 
> I didn't previously see this email, but the point is that this is a bug - dd should not 
> require first making calculations based on the size of each drive or using the smallest 
> possible block size (and hence taking a ridiculous amount of time) in order to do what 

Do you have any metrics that it is faster, by any meaningful amount? If so I would be very interested in mitigating it, but I suspect not the actual case.

> it's meant to do. It should always wipe the last sector of the drive regardless, just 
> as it does on other UNIX-like systems. This is why this behaviour is a bug that 
> needs to be fixed.

This does not appear to be a bug, but user error. Per the DD source "Some devices require alignment 
on a sector or page boundary"

DD has never "dealt with error handling" except when conversion were in play. When no conversions are in play it 

            {
              /* Write any partial block. */
              exit_status = EXIT_FAILURE;
              break;
            }

On windows the block devices require respecting block device boundaries, any change would be an upstream patch - not a Cygwin patch.

Sorry if this sounds rough.

Respectfully,

Jason Pyeron

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple