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.LFD.2.02.1208231722040.2856@ionos>
Date:	Thu, 23 Aug 2012 17:46:21 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Attilio Rao <attilio.rao@...rix.com>
cc:	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, Stefano.Stabellini@...citrix.com,
	konrad.wilk@...cle.com
Subject: Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for
 x86_init.mapping.pagetable_reserve

On Wed, 22 Aug 2012, Attilio Rao wrote:

> - Allow xen_mapping_pagetable_reserve() to handle a start different from
>   pgt_buf_start, but still bigger than it.

What's the purpose of this and how is this going to be used and how is
it useful at all?

> - Add checks to xen_mapping_pagetable_reserve() and native_pagetable_reserve()
>   for verifying start and end are contained in the range
>   [pgt_buf_start, pgt_buf_top].
> - In xen_mapping_pagetable_reserve(), change printk into pr_debug.
> - In xen_mapping_pagetable_reserve(), print out diagnostic only if there is
>   an actual need to do that (or, in other words, if there are actually some
>   pages going to switch from RO to RW).

Please stop telling what the patch is doing. I can read that from the
patch itself. Please tell _WHY_ it is doing it.
 
> Signed-off-by: Attilio Rao <attilio.rao@...rix.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> Acked-by: Stefano Stabellini <stefano.stabellini@...citrix.com>
> ---
>  arch/x86/mm/init.c |    4 ++++
>  arch/x86/xen/mmu.c |   22 ++++++++++++++++++++--
>  2 files changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index e0e6990..f4b750d 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -92,6 +92,10 @@ static void __init find_early_table_space(struct map_range *mr, unsigned long en
>  
>  void __init native_pagetable_reserve(u64 start, u64 end)
>  {
> +	if (start < PFN_PHYS(pgt_buf_start) || end > PFN_PHYS(pgt_buf_top))

This check is useless. We initialize pgt_buf_start,end,top to:

        pgt_buf_start = base >> PAGE_SHIFT;
        pgt_buf_end = pgt_buf_start;
        pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);

in find_early_table_space(). pgt_buf_end gets modified only in
alloc_low_page()

        unsigned long pfn = pgt_buf_end++;

And both implementations (32/64bit) have the following check:

        if (pfn >= pgt_buf_top)
                panic("alloc_low_page: ran out of memory");

So we panic way before we reach this check. Extra panic safety or what
are you trying to do here? 

I also have a hard time to understand the first part of the check.
There is only one callsite which feeds PFN_PHYS(pgt_buf_start) as
first argument. And as long as you don't explain WHY it would be
useful and a good idea to change that, this is pointless.

> +		panic("Invalid address range: [%#llx-%#llx] should be a subset of [%#llx-%#llx]\n",
> +			start, end, (u64)PFN_PHYS(pgt_buf_start),
> +			(u64)PFN_PHYS(pgt_buf_top));
>  	memblock_reserve(start, end - start);
>  }
>  
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b65a761..dfae43a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1180,12 +1180,30 @@ static void __init xen_pagetable_setup_start(pgd_t *base)
>  
>  static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
>  {
> +	u64 begin;
> +
> +	begin = PFN_PHYS(pgt_buf_start);
> +
> +	if (start < begin || end > PFN_PHYS(pgt_buf_top))
> +		panic("Invalid address range: [%#llx-%#llx] should be a subset of [%#llx-%#llx]\n",
> +			start, end, begin, (u64)PFN_PHYS(pgt_buf_top));
> +
> +	/* set RW the initial range */
> +	if  (start != begin)

And how does this happen? Again, that function is called from one
place and start _IS_ equal to PFN_PHYS(pgt_buf_start).

> +		pr_debug("xen: setting RW the range [%#llx-%#llx]\n",
> +			begin, start);
> +	while (begin < start) {
> +		make_lowmem_page_readwrite(__va(begin));
> +		begin += PAGE_SIZE;
> +	}
> +
>  	/* reserve the range used */
>  	native_pagetable_reserve(start, end);
>  
>  	/* set as RW the rest */
> -	printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
> -			PFN_PHYS(pgt_buf_top));
> +	if (end != PFN_PHYS(pgt_buf_top))

So this check is the only useful addition of this patch so far, unless
you come up with some useful explanations.

> +		pr_debug("xen: setting RW the range [%#llx-%#llx]\n",
> +			end, (u64)PFN_PHYS(pgt_buf_top));

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ