From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.pdinc.us (mail2.pdinc.us [67.90.184.28]) by sourceware.org (Postfix) with ESMTPS id 7151D385480B for ; Tue, 29 Dec 2020 02:41:23 +0000 (GMT) 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@pdinc.us Received: from lovegrove (nsa1.pdinc.us [67.90.184.2]) (authenticated bits=0) by mail2.pdinc.us (8.14.4/8.14.4) with ESMTP id 0BT2fLuj031021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Dec 2020 21:41:21 -0500 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" To: References: <1d1801d64677$bea56050$3bf020f0$@pdinc.us> <60bf1507-4edb-a03f-ec14-07e1ab7f0d94@cs.umass.edu> , <1b13fde4-0834-cd8b-0673-c2b14bbaa372@SystematicSw.ab.ca> In-Reply-To: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 02:41:24 -0000 > -----Original Message----- > From: Hashim Aziz via Cygwin > Sent: Monday, December 28, 2020 7:46 PM >=20 >> From: Cygwin on behalf of Brian Inglis >> >> Sent: 23 June 2020 8:33 PM >> To: cygwin@cygwin.com >> Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk >>=20 >> 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. >=20 > 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=3Dfullblock ? This causes special handling. > Sent: Monday, December 28, 2020 7:25 PM > To: Jason Pyeron=20 >=20 > I didn't previously see this email, but the point is that this is a = bug - dd should not=20 > require first making calculations based on the size of each drive or = using the smallest=20 > possible block size (and hence taking a ridiculous amount of time) in = order to do what=20 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=20 > as it does on other UNIX-like systems. This is why this behaviour is a = bug that=20 > needs to be fixed. This does not appear to be a bug, but user error. Per the DD source = "Some devices require alignment=20 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=20 { /* Write any partial block. */ exit_status =3D 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