linux-kernel - Re: Rootfs in eMMC: Kernel panic ...Attempted to kill init!

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: <20090622155659.GE29188@n2100.arm.linux.org.uk>
Date:	Mon, 22 Jun 2009 16:56:59 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Sudeep K N <sudeepholla.maillist@...il.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk, drzeus-mmc@...eus.cx,
	linux-kernel@...r.kernel.org
Subject: Re: Rootfs in eMMC: Kernel panic ...Attempted to kill init!

On Mon, Jun 22, 2009 at 04:50:46PM +0100, Catalin Marinas wrote:
> On Mon, 2009-06-22 at 16:43 +0100, Russell King - ARM Linux wrote:
> > On Mon, Jun 22, 2009 at 07:43:40PM +0530, Sudeep K N wrote:
> > > Thanks for the suggestion.
> > > With the logs it is clear that crash is in the userspace.
> > > I am getting one of the 2 logs(below) randomly.
> > > >From trial#2,
> > > pgd = c60bc000
> > > [00000000] *pgd=061ee031, *pte=00000000, *ppte=00000000
> > > I could understand that the page tables are not proper.
> > > I am not able understand how to proceed.
> > > 
> > > Trial#1:
> > > VFS: Mounted root (ext2 filesystem).
> > > Freeing init memory: 108K
> > > linuxrc (1): undefined instruction: pc=40008100
> > > Code: e08e3003 eb002842 e2801008 e58c217c (e0812103)
> > 
> > Your processor is misbehaving; none of the above hex codes are undefined
> > instructions, so you shouldn't be taking an undefined instruction trap.
> 
> The undefined instruction aborts are possible in this situation since
> instructions are fetched via the I-cache while the abort handler shows
> the code via the D-cache.

However, you're missing a very important point.

This early on, the I-cache for the non-kernel pages won't contain any
entries except those placed there by this first binary - it's the very
first user process which is receiving these exceptions.

Second point is that the page concerned has only recently been mapped
into that page.  I would be very very surprised if speculative
instruction prefetch managed to dirty the exact right page via the
kernel mapping to always cause the first process to fail in some way.
--
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/