linux-kernel - Re: [Xen-devel] [PATCH 7/7] xen/mmu: Remove from _

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: <alpine.DEB.2.02.1207271230150.26163@kaball.uk.xensource.com>
Date:	Fri, 27 Jul 2012 12:31:17 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [Xen-devel] [PATCH 7/7] xen/mmu: Remove from __ka space PMD
 entries for pagetables.

On Thu, 26 Jul 2012, Konrad Rzeszutek Wilk wrote:
> Please first read the description in "xen/mmu: Copy and revector the
> P2M tree."
> 
> At this stage, the __ka address space (which is what the old
> P2M tree was using) is partially disassembled. The cleanup_highmap
> has removed the PMD entries from 0-16MB and anything past _brk_end
> up to the max_pfn_mapped (which is the end of the ramdisk).
> 
> The xen_remove_p2m_tree and code around has ripped out the __ka for
> the old P2M array.
> 
> Here we continue on doing it to where the Xen page-tables were.
> It is safe to do it, as the page-tables are addressed using __va.
> For good measure we delete anything that is within MODULES_VADDR
> and up to the end of the PMD.
> 
> At this point the __ka only contains PMD entries for the start
> of the kernel up to __brk.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> ---
>  arch/x86/xen/mmu.c |   20 ++++++++++++++++++++
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 05e8492..738feca 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1241,6 +1241,26 @@ static void __init xen_pagetable_setup_done(pgd_t *base)
>  			xen_start_info->mfn_list = new_mfn_list;
>  		}
>  	}
> +#ifdef CONFIG_X86_64
> +	/* At this stage, cleanup_highmap has already cleaned __ka space
> +	 * from _brk_limit way up to the max_pfn_mapped (which is the end of
> +	 * the ramdisk). We continue on, erasing PMD entries that point to page
> +	 * tables - do note that they are accessible at this stage via __va.
> +	 * For good measure we also round up to the PMD - which means that if
> +	 * anybody is using __ka address to the initial boot-stack - and try
> +	 * to use it - they are going to crash. The xen_start_info has been
> +	 * taken care of already in xen_setup_kernel_pagetable. */
> +	addr = xen_start_info->pt_base;
> +	size = roundup(xen_start_info->nr_pt_frames * PAGE_SIZE, PMD_SIZE);
> +
> +	xen_cleanhighmap(addr, addr + size);
> +	xen_start_info->pt_base = (unsigned long)__va(__pa(xen_start_info->pt_base));
> +
> +	/* This is superflous and shouldn't be neccessary, but you know what
> +	 * lets do it. The MODULES_VADDR -> MODULES_END should be clear of
> +	 * anything at this stage. */
> +	xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1);

I would stick an #ifdef CONFIG_DEBUG of some kind around it


> +#endif
>  	xen_post_allocator_init();
>  }
>  
> -- 
> 1.7.7.6
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@...ts.xen.org
> http://lists.xen.org/xen-devel
> 
--
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/