linux-kernel - Re: Oops with DCACHE_WORD

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:	Thu, 3 May 2012 09:15:41 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Nick Piggin <npiggin@...il.com>, Jana Saout <jana@...ut.de>,
	Joel Becker <jlbec@...lplan.org>, linux-kernel@...r.kernel.org
Subject: Re: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4

On Wed, May 2, 2012 at 11:47 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> What I'd really like to know is whether we can hit the same kind of "steps
> off the end of page" crap on pagecache based symlinks with very long bodies.
> The upper limit is 4K, which allows that sucker to reach the end of page
> on most of the architectures.  And that can be done on just about any fs
> supporting symlinks at all - create a symlink with the long body (up to the
> limit), something like (("./"x2047)."a").

Sure. And I've even tested that. You don't need a symlink, you can
have just a regular system call that passes a filename that is 4095
bytes long, and ends in a short component. We *will* access the next
page.

And that was always understood to be the case for the
DCACHE_WORD_ACCESS patches. It's just that accessing the next page
should be entirely harmless on any actual real x86 implementation.

Well, except for the DEBUG_PAGEALLOC case, which is why it's disabled
for that case.

And apparently except for some Xen PV case, where we have similar
issues, and which seems to be the reason Jana sees the problems.

I don't know the Xen paravirtualization code, but it looks like it is
punching holes in the kernel memory map, so you get the same issue you
get with DEBUG_PAGEALLOC.

Actually, looking at things, I think there's another case that can do
it: the AMD gart_64 code also does set_memory_np(), which can cause
problems.

So I guess I need to do the exception handling that I was hoping I
wouldn't have to. Give me a jiffy.

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