linux-kernel - Re: amd64 sata_nv (massive) memory corruption

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]

Date:	Sun, 3 Aug 2008 23:16:28 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	linasvepstas@...il.com
Cc:	"John Stoffel" <john@...ffel.org>,
	"Alistair John Strachan" <alistair@...zero.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: amd64 sata_nv (massive) memory corruption

> I then did some more debugging, and isolated the original data corruption
> problem to a bad pair of RAM sticks. But this was subtle, so let me recap:
> 
> -- The bad ram passes memtest86+

You are assuming bad RAM then not bad bus loadings, corrosion on the
pins.. ?

> So I'm wondering: can we devise a test to validate system-bus interactions
> like this? Clearly, the memtest86 test validates the RAM and the northbridge
> bus between CPU and system RAM, so that seems OK.

If you have a good enough pile of hardware and the right monitoring stuff
loaded then you should get EDAC event logs from the PCI/PCI-X for PCI
card logged traps, MCE errors for the higher level busses, L1/L2 cache or
CPU parity errors and ECC traps for memory problems either via EDAC or
MCE.

If you are using a generic end user motherboard then you don't.

> doesn't exist. I have no clue about SATA.  Is there possibly some ide or
> scsi command that can be used to loop-back? Some sort of "send bytes
> to disk, but don't actually write them to platter" command? Maybe just
> a write to some scratch ram on the disk drive itself? Even just a few bytes

Yes for SCSI. In theory yes for ATA but I've never tested to see what the
level of actual support is, and I'm not sure you can test it in DMA mode.

> would be enough to implement a loopback test. Maybe some sort of

For the simpler cases perhaps. The more interesting approaches I think
are the fs level ones where you accept the fact that hardware sucks and
do end to end checksumming from the fs or even the app in some
situations. We don't yet have that functionality mainstream although it
might make an interesting device mapper module ...

Alan
--
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/