linux-kernel - Re: crashme fault

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: <20070916220643.bea3e44f.randy.dunlap@oracle.com>
Date:	Sun, 16 Sep 2007 22:06:43 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	Zachary Amsden <zach@...are.com>
Subject: Re: crashme fault

On Sun, 16 Sep 2007 11:12:23 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Sun, 16 Sep 2007, Linus Torvalds wrote:
> > 
> > I'm really starting to suspect some early EM64T bug, and I also suspect 
> > that it's harmless but that we should just do the trivial patch to say "if 
> > the register state is in user mode, we don't care if the CPU says it was a 
> > kernel access".
> 
> Namely something like this..
> 
> The basic idea is that it's pointless to test for "error_code & PF_USER" 
> to decide whether we should oops or kill the process: the *real* issue is 
> whether we *can* kill the process or not. And that depends not on whether 
> the CPU claimed it was a user access or not, but on whether the register 
> state we'd return to is user-mode or not!
> 
> So anything that decides whether it should send a signal or do to the 
> "no_context" Ooops path should use "user_mode_vm(regs)" (yeah, I realize 
> that the "_vm" part is unnecessary on x86-64, but it doesn't hurt either, 
> and all of the issues are the same on 32/64-bit) which tests the right 
> thing.
> 
> Now, normally the USER bit in the error code should be the exact same 
> thing, except for
> 
>  - Some CPU bug (microcode issue, whatever) where some complex fault 
>    situation sets the wrong error code.
> 
>  - user space accesses that caused a system page fault (ie a page fault 
>    while handling another trap - possibly due to lazy page table setup 
>    and having the LDT or some other CPU data structure in vmalloc space)
> 
> Now, the vmalloc space accesses should be handled separately anyway, so I 
> really wonder if it's some subtle CPU bug (I can't reproduce any problems 
> on my Core 2 Duo), but the point is that I think this patch really is 
> conceptually a real fix regardless, even if it _shouldn't_ matter.
> 
> Comments?
> 
> Randy, this replaces the hacky patch I sent, but also shuts up about the 
> odd thing you're hitting, so for testing your case further this may not be 
> the right thing. However, it would be nice to hear whether this just makes 
> "crashme" work properly for you without any side effects..

I'll test this overnight on 2.6.23-rc6-git2 since that was failing.

I haven't been able to reproduce the fault on 2.6.21 after several
hours of testing.

I'll also test a microcode update to see if it helps.

---
~Randy
-
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/