* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [071213 04:48]:
> On Fri, Dec 07, 2007 at 02:22:30PM +0200, Hiroshi DOYU wrote:
> > > > +
> > > > + /* zap pte */
> > > > + end = pmd_page_vaddr(*pmdp);
> > > > + ptep = end - PTRS_PER_PTE;
> > > > + while (ptep < end) {
> > > > + if (!pte_none(*ptep))
> > > > + goto out;
> > > > + ptep++;
> > > > + }
> > > > + pte_free_kernel(pmd_page_vaddr(*pmdp));
> > >
> > > So you free the PMD table.
> > >
> > > > +
> > > > + invalidate_pmd:
> > > > + pmd_clear(pmdp);
> > > > + flush_pmd_entry(pmdp);
> > >
> > > and then remove it from the page tables. Two problems - if the entries
> > > have been copied to another task, you'll be leaving the PMD table present
> > > there. Secondly, if you're using this with SMP it's hellishly racy.
> > > (which is why we don't support section mappings in ioremap on SMP.)
> >
> > For the first case, this pagetable is dedicated only to each
> > coprocessor and the coprocessor's MMU is independent of ARM side MMU
> > from H/W point of view. This code just manages the consistency between
> > the kernel pagetable(init_mm) and the coprocessor's pagetable against
> > real physical address at the same time. So this coprocessor's
> > pagetable itself isn't duplicated even when forking.
>
> You haven't understood the problem at all.
>
> You are setting up kernel L1 table entries in the kernels init_mm page
> tables.
>
> When ever you perform an access to mappings setup there, and some other
> thread is running, those page table entries get copied to the threads
> private L1 tables.
>
> If you then tear down the kernel L1 table entries, references to those
> page tables persist from other threads private L1 tables.
>
> So, if you NULL out the entry in the init_mm and free the page, you've
> got a very real potential for something to access a page which has been
> freed - possibly writing to it. Moreover, if that page gets re-used in
> such a way that userspace can then access it, you've a security hole.
>
> I would much rather you did NOT implement L1 table manipulation yourself;
> it is a good way to introduce serious bugs into the kernel if you do not
> properly and fully understand how the page tables and threads work.
> Instead, I suggest you look around the kernel and see how you can re-use
> code which already does this, possibly by modifying it. ioremap() would
> be a good place to start because it already correctly deals with these
> issues for the uniprocessor case.
I've posted the patch series to the patch system without the MMU patch [1].
This way Hiroshi has a bit more time to deal with the issues.
Regards,
Tony
[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4716/1
-
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
