From: Hashim Aziz <hashaziz@hotmail.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: [cygwin] DD bug fails to wipe last 48 sectors of a disk
Date: Tue, 29 Dec 2020 00:46:14 +0000 [thread overview]
Message-ID: <DB7PR01MB5193BA73A9E8E08912AEBADED5D80@DB7PR01MB5193.eurprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <1b13fde4-0834-cd8b-0673-c2b14bbaa372@SystematicSw.ab.ca>
________________________________
From: Cygwin <cygwin-bounces@cygwin.com> on behalf of Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Sent: 23 June 2020 8:33 PM
To: cygwin@cygwin.com <cygwin@cygwin.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.
next prev parent reply other threads:[~2020-12-29 0:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 18:19 Hashim Aziz
[not found] ` <1d1801d64677$bea56050$3bf020f0$@pdinc.us>
2020-06-20 17:31 ` [cygwin] " Hashim Aziz
2020-06-20 20:26 ` Eliot Moss
2020-06-23 15:28 ` Hashim Aziz
2020-06-23 15:29 ` Eliot Moss
2020-06-23 16:06 ` Nicholas Clark
2020-06-23 19:46 ` Hashim Aziz
2020-06-24 10:21 ` Andrey Repin
2020-06-25 12:08 ` Hashim Aziz
2020-06-25 13:25 ` Brian Inglis
2020-06-28 14:34 ` Christian Franke
2020-06-28 17:50 ` Jason Pyeron
2020-06-28 20:28 ` Brian Inglis
2020-06-23 19:33 ` Brian Inglis
2020-12-29 0:46 ` Hashim Aziz [this message]
2020-12-29 2:41 ` Jason Pyeron
2020-12-29 17:54 ` Brian Inglis
2020-12-30 1:35 ` Jason Pyeron
[not found] ` <DB7PR01MB5193B13815933B913D11DDC2D5D20@DB7PR01MB5193.eurprd01.prod.exchangelabs.com>
2021-01-04 21:08 ` Jason Pyeron
2020-08-04 22:42 ` Hashim Aziz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB7PR01MB5193BA73A9E8E08912AEBADED5D80@DB7PR01MB5193.eurprd01.prod.exchangelabs.com \
--to=hashaziz@hotmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).