linux-kernel - Re: Xen MMU's requirement to pin pages RO and initial_memory

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: <20110517180520.GC13706@dumpdata.com>
Date:	Tue, 17 May 2011 14:05:20 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc:	"yinghai@...nel.org" <yinghai@...nel.org>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"hpa@...ux.intel.com" <hpa@...ux.intel.com>,
	Ian Campbell <Ian.Campbell@...citrix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: Xen MMU's requirement to pin pages RO and initial_memory_mapping.

On Tue, May 17, 2011 at 06:50:55PM +0100, Stefano Stabellini wrote:
> On Mon, 16 May 2011, Konrad Rzeszutek Wilk wrote:
> > > They become pagetable pages when:
> > > 
> > > - they are explicitly pinned by pin_pagetable_pfn
> > > 
> > > - they are hooked into the current pagetable
> > 
> > Ok, so could we use those two calls to trigger the pagetable walk
> > and mark them RO as appropiate? Which call sites are those? The
> > xen_set_pgd/xen_set_pud/xen_set_pmd ?
> 
> xen_alloc_pte_init and xen_alloc_pmd_init are the ones that mark the
> pagetable pages RO and pin them, calling make_lowmem_page_readonly and
> pin_pagetable_pfn.
> 
> alloc_pte/pmd are called right before hooking them into the pagetable;
> unfortunately that means that they fail at marking the pagetable pages
> RO: make_lowmem_page_readonly uses lookup_address to find the pte
> corresponding to a page, however at this point the pagetable pages are
> not mapped yet (usually they are not hooked but when they are hooked, the
> upper level pagetable page is not hooked), so lookup_address fails.

Right. We don't have to walk the hooked pagetable, I think. We are passed
in the PMD/PGD of the PFN and we could look at the content of that PFN.
Walk each entry in there and for those that are present, determine
if the page table it points to (whatever level it is) is RO. If not, mark
it RO. And naturally do it recursively to cover all levels.

> 
> In order to catch these errors Xen has a parachute: xen_set_pte_init,
> the function that takes care of writing a pte to memory and that on xen
> converts pfns to mfns, also marks pagetable pages RO trying to
> understand when that is appropriate.
> 
> This is all very ugly and delicate.

And complex.
> 
> I think alloc_pte/pmd were always thought to be used to mark and pin
> pagetable pages but they currently fail during the initial pagetable
> setup. If we could fix alloc_pte/pmd most of the problems and the hacks
> would go away.

Yeey!
> Ideally we could remove both mask_rw_pte (currently responsible for
> marking pagetable pages RO, called from xen_set_pte_init) and
> x86_init.mapping.pagetable_reserve.
> 
> More thinking (and caffeine) needed...
> 
> 
> 
> 
> > Presumarily we don't have
> > to do that for the PTE's that are already mapped (as
> > xen_setup_kernel_pagetable, and xen_map_identity_early do this
> > already).
> 
> No, we don't.
> We do need to make sure they stay RO on x86_32 where we write the
> pagetable pages in two steps and we switch pagetable to swapper_pg_dir.

And then vice-versa later on during the bootup.
--
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/