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 16:23:41 +1000
From:	Nick Piggin <npiggin@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jana Saout <jana@...ut.de>, Joel Becker <jlbec@...lplan.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4

On 3 May 2012 15:57, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Wed, May 2, 2012 at 10:02 PM, Nick Piggin <npiggin@...il.com> wrote:
>> Linus did you see this thread?
>
> I did not..
>
>>Any ideas what is going on?
>
> Note that the discussion about aligned allocations is irrelevant. It
> doesn't matter at all if the pathname allocation is aligned - what
> matters if whether the last *component* of the pathname is aligned or
> not, and that is not going to depend on the allocation alignment.
>
> The word-at-a-time code assumes that no allocation will be the last
> page (whether kmalloc or normal page allocation), which was always
> somewhat optimistic but I thought it would be true on PC's.
>
> And that %rbp value does *not* look like end-of-memory, but maybe
> there is something else than just the CONFIG_DEBUG_PAGEALLOC that
> causes us to punch holes even in the kernel memory map.
>
> Peter, Ingo - do we unmap kernel pages for PAT etc attributes?
>
> Jana, can you send me the whole dmesg for the bootup up to and
> including the oops?
>
> There are multiple ways to fix this, including just marking that
> unaligned word access as being able to take an exception, but I had
> hoped to avoid having to do that. There are alternatives, like always
> padding allocations up by 7 bytes, but those are nasty too. So I'd
> like to understand what triggers this for Jana, it's possible we can
> just work around that particular issue.

Ah, I see what you mean. kmalloc is padded to 8 bytes, but that's
irrelevant if the full string was exactly modulo 8 bytes long, but the
last component starts inside the last 8 bytes.

That seems to exonerate OCFS2 and autofs.

vmalloc of course does guard pages, and that creeps into percpu
data and other things. It's not the case here, but would it be worth
putting a check in to catch that, or is it just a totally insane thing
to pass vmalloc()/percpu_alloc()/etc name string?

Any other strange possible corner cases? If we put a string on stack,
do any architectures use vmalloc or anything strange for stacks?
--
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/