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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 16 Mar 2012 14:09:32 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	George Spelvin <linux@...izon.com>
Cc:	jkosina@...e.cz, jack@...e.cz, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Oops in ext3_block_to_path.isra.40+0x26/0x11b

On Fri, Mar 16, 2012 at 2:04 PM, George Spelvin <linux@...izon.com> wrote:
>
> Unfortunately, this is the only time it's happened to me with kernel
> modesetting *on*.  Would repeated checksums of a kernel tree be a good
> way to detect random memory stomping?

Yes, doing filesystem checksums tends to be a good way to find memory
corruption, since a lot of memory tends to be caches.

Another approach is to have a stupid program that allocates an array
of say about half the physical memory, and writes some nicely
recognizable pattern to it. Then, every minute or two, re-check the
pattern.

The advantage of the pattern approach is that it makes it possible to
show things like "these X bytes at offset Y in the page changed",
which can give hints about the source of corruption. The full virtual
address is obviously useless, but the "offset within page" can be
quite useful for figuring out corruption patterns even if you can't
necessarily see which physical page it actually is.

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists