linux-kernel - Re: [BUG] 2.6.25-rc3 hangs in early boot on Sun Ultra5

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:	Wed, 27 Feb 2008 20:16:17 +0100
From:	Mikael Pettersson <mikpe@...uu.se>
To:	David Miller <davem@...emloft.net>
Cc:	mikpe@...uu.se, sparclinux@...r.kernel.org,
	linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [BUG] 2.6.25-rc3 hangs in early boot on Sun Ultra5

David Miller writes:
 > From: David Miller <davem@...emloft.net>
 > Date: Tue, 26 Feb 2008 16:49:00 -0800 (PST)
 > 
 > [ Thomas, forgot to CC: you earlier, changeset
 >   a0c1e9073ef7428a14309cba010633a6cd6719ea ("futex: runtime enable pi
 >   and robust functionality") broke sparc64. ]
 > 
 > > From: Mikael Pettersson <mikpe@...uu.se>
 > > Date: Tue, 26 Feb 2008 09:55:50 +0100
 > > 
 > > > Minor update: rc2-git7 has the slow initial console behaviour,
 > > > but successfully switches to the framebuffer. rc2-git8 however
 > > > hangs in the console handover. So I'll bisect git7->git8 next.
 > > 
 > > Between the VT layer registering it's console and the atyfb
 > > driver initializing we get a crash, and it happens on all
 > > sparc64 systems.  It is caused by this commit and I am working
 > > on a fix:
 > 
 > The following patch will let things "work" but the trick being used
 > here by the FUTEX layer is borderline valid in my opinion.
 > 
 > Basically for 10+ years on sparc64 we've had this check here in the
 > fault path, which makes sure that if we're processing an exception
 > table entry we really, truly, are doing an access to userspace from
 > the kernel.  Otherwise we OOPS.
 > 
 > What the FUTEX checking code is doing now is doing a "user" access
 > with set_fs(KERNEL_DS) since it runs from the kernel bootup early init
 > sequence.  And this is illegal according to the existing checks.
 > 
 > When we do set_fs(KERNEL_DS) then pass a "user" pointer down
 > into a system call or something like that, we give it a pointer
 > that "cannot fault".  So if we get into the fault handling
 > path here for a case like that we really do want to scream and
 > print out an OOPS message in my opinion.
 > 
 > I realize that not many platforms other than sparc64 can check
 > for things this precisely, but it's something to consider.
 > 
 > Did this FUTEX change go into -stable too?
 > 
 > diff --git a/arch/sparc64/mm/fault.c b/arch/sparc64/mm/fault.c
 > index e2027f2..9183633 100644
 > --- a/arch/sparc64/mm/fault.c
 > +++ b/arch/sparc64/mm/fault.c
 > @@ -244,16 +244,8 @@ static void do_kernel_fault(struct pt_regs *regs, int si_code, int fault_code,
 >  	if (regs->tstate & TSTATE_PRIV) {
 >  		const struct exception_table_entry *entry;
 >  
 > -		if (asi == ASI_P && (insn & 0xc0800000) == 0xc0800000) {
 > -			if (insn & 0x2000)
 > -				asi = (regs->tstate >> 24);
 > -			else
 > -				asi = (insn >> 5);
 > -		}
 > -	
 > -		/* Look in asi.h: All _S asis have LS bit set */
 > -		if ((asi & 0x1) &&
 > -		    (entry = search_exception_tables(regs->tpc))) {
 > +		entry = search_exception_tables(regs->tpc);
 > +		if (entry) {
 >  			regs->tpc = entry->fixup;
 >  			regs->tnpc = regs->tpc + 4;
 >  			return;
 > 

Thanks, 2.6.25-rc3 plus this patch works fine on my Ultra5.

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