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]
Date:	Fri, 03 Jul 2009 11:56:00 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	lkml@...eThan.org
CC:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Bug Fix]: Do 32-bit table calculations in pre-processor

On 07/03/09 11:14, Michael S. Zick wrote:
> Here is one I have found useful in my VIA processor bug hunting:
>
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 3068388..2303d86 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -61,7 +61,7 @@
>
>  /* Enough space to fit pagetables for the low memory linear map */
>  MAPPING_BEYOND_END = \
> -       PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> +       PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>
>   

These calculations are performed by the assembler, not the
preprocessor.  I think this transformation looks correct (in that its an
identity with the original), but my understanding is that the assembler
does it calculations in arbitrary precision, so there's no need to worry
about limiting the arithmetic to 32-bits.

>  /*
>   * Worst-case size of the kernel mapping we need to make:
>
> = = =
>
> Before:
>
>   #5 [0000010000 - 0000011000]          PGTABLE ==> [0000010000 - 0000011000]
>   #6 [0000011000 - 0000015000]          BOOTMAP ==> [0000011000 - 0000015000]
>
> After:
>
>   #5 [0000010000 - 000007d000]          PGTABLE ==> [0000010000 - 000007d000]
>   #6 [000007d000 - 0000081000]          BOOTMAP ==> [000007d000 - 0000081000]
>
> Someone who knows mm check which is the reasonable value please.
>   


The PGTABLE reservation seems much too big.  I think 1 page should be
sufficient for a system with large pages.  Even if not, 0x6d000 is way
too large.  And they symptoms of failing to reserve the initial
pagetable are pretty non-subtle.

    J
--
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