linux-kernel - Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061202051720.GA12580@tuatara.stupidest.org>
Date:	Fri, 1 Dec 2006 21:17:20 -0800
From:	Chris Wedgwood <cw@...f.org>
To:	Christoph Anton Mitterer <calestyo@...entia.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote:

> I found a severe bug mainly by fortune because it occurs very
> rarely.  My test looks like the following: I have about 30GB of
> testing data on my harddisk,... I repeat verifying sha512 sums on
> these files and check if errors occur.

Heh, I see this also with an Tyan S2866 (nforce4 chipset).  I've been
aware something is a miss for a while because if I transfer about 40GB
of data from one machine to another there are checksum mismatches and
some files have to be transfered again.

I've kept quite about it so far because it's not been clear what the
cause is and because i can mostly ignore it now that I checksum all my
data and check after xfer that it's sane (so I have 2+ copies of all
this stuff everywhere).

> One test pass verifies the 30GB 50 times,... about one to four
> differences are found in each pass.

Sounds about the same occurance rate I see, 30-40GB xfer, one or two
pages (4K) are wrong.

> The corrupted data is not one single completely wrong block of data
> or so,.. but if you look at the area of the file where differences
> are found,.. than some bytes are ok,.. some are wrong,.. and so on
> (seems to be randomly).

For me it seems that a single block in the file would be bad and the
rest OK --- we I'm talking about 2 random blocks in 30BG or so.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/