linux-kernel - Re: bcm33xx port

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:	Mon, 9 Jun 2008 01:05:28 -0500
From:	Luke -Jr <luke@...hjr.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mips@...ux-mips.org
Subject: Re: bcm33xx port

On Sunday 08 June 2008, Maciej W. Rozycki wrote:
> On Sun, 8 Jun 2008, Luke -Jr wrote:
> > >  I have seen that already and wrote these stores in __bzero are
> > > protected. Perhaps the fixup fails for some reason, but you need to
> > > investigate it and this is why I suggested to see how the RI handler is
> > > reached.  Since this is a known point the failure leads to, you should
> > > be able to work backwards from there quite easily.
> >
> > Ah, so what you're saying is that perhaps the 'sw' is triggering a TLB
> > exception, and the handler for *that* is causing the RI problem?
>
>  This is almost certain what happens here.  The pointer involved is a
> valid (user) address and is correctly aligned, so you cannot get an
> address error exception.  A TLB exception is next on the list to check.

I added some code to do_ri:
	if (unlikely(!user_mode(regs)))
	{
		long real_epc;
		asm("move %0, $sp" : "=r"(real_epc));
		printk("----- LJR -------\n");
		show_raw_backtrace(real_epc);
		printk("----- LJRx-------\n");
	}

Which gave me some potentially useful info:
	----- LJR -------
	Call Trace:
	[<80011460>] ret_from_exception+0x0/0x24
	[<80069de4>] vma_link+0x48/0x114
	[<8001b1f0>] blast_icache16+0x0/0xec
	[<800aa27c>] padzero+0x5c/0x74
	[<800c6774>] __bzero+0x38/0x164
	[<800ab04c>] load_elf_binary+0x948/0x145c
	[<800aac6c>] load_elf_binary+0x568/0x145c
	[<80083b80>] __path_lookup_intent_open+0x60/0xe4
	[<80083b50>] __path_lookup_intent_open+0x30/0xe4
	[<80080044>] permission+0x10c/0x148
	[<8007bfd4>] search_binary_handler+0x78/0x18c
	[<800aa15c>] load_script+0x25c/0x270
	[<800aa148>] load_script+0x248/0x270
	[<800aa7b4>] load_elf_binary+0xb0/0x145c
	[<8007c204>] get_arg_page+0x4c/0xc4
	[<8001cab4>] r4k_flush_cache_page+0x1c/0x28
	[<8007bfd4>] search_binary_handler+0x78/0x18c
	[<8007e004>] do_execve+0x18c/0x258
	[<8007dfe4>] do_execve+0x16c/0x258
	[<80081074>] getname+0x24/0x118
	[<8001570c>] sys_execve+0x4c/0x78
	[<80030610>] release_console_sem+0x114/0x358
	[<80018410>] stack_done+0x20/0x3c
	[<80031038>] vprintk+0x368/0x448
	[<8007554c>] get_unused_fd_flags+0x60/0x184
	[<80081074>] getname+0x24/0x118
	[<80010478>] init_post+0x60/0xe8
	[<80015584>] kernel_execve+0x8/0x20
	[<800136cc>] kernel_thread_helper+0x10/0x18
	[<800136bc>] kernel_thread_helper+0x0/0x18
	
	----- LJRx-------

Too tired to debug further tonight, but hopefully this stack will stand out to 
someone :)

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