linux-kernel - Re: [patch] mm: sparsemem memory_present() memory corruption fix

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: <86802c440804151817h7b530e95i568e4313c32636c2@mail.gmail.com>
Date:	Tue, 15 Apr 2008 18:17:24 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Christoph Lameter" <clameter@....com>,
	linux-kernel@...r.kernel.org, "Mel Gorman" <mel@....ul.ie>,
	"Nick Piggin" <npiggin@...e.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, apw@...dowen.org,
	"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [patch] mm: sparsemem memory_present() memory corruption fix

On Tue, Apr 15, 2008 at 6:02 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
>  * Yinghai Lu <yhlu.kernel@...il.com> wrote:
>
>  > On Tue, Apr 15, 2008 at 5:44 PM, Ingo Molnar <mingo@...e.hu> wrote:
>  > >
>  > >  * Yinghai Lu <yhlu.kernel@...il.com> wrote:
>  > >
>  > >  > >  +       unsigned long max_arch_pfn = 1ULL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
>  > >  > >
>  > >  > >  and also check my analysis whether it is correct and whether it
>  > >  > >  matches the reported bug patterns. But otherwise the fix looks like
>  > >  > >  a safe fix for v2.6.25-final to me - it only filters out values
>  > >  > >  from sparsemem input that are nonsensical in the sparsemem
>  > >  > >  framework anyway.
>  > >  >
>  > >
>  > > > can you check why find_max_pfn() e820_32.c need to call
>  > >  > memory_present? wonder if it can be removed.
>  > >
>  > >  this is the only call to memory_present() we do in 32-bit arch setup, so
>  > >  it's required.
>  > >
>  > >  (the function find_max_pfn() is woefully misnamed, but that's a cleanup
>  > >  - i just fixed this in x86.git.)
>  >
>  > 64 bit is calling that via paging_init
>  > ==>sparse_memory_present_with_active_regions(MAX_NUMNODES).
>  >
>  > and
>  > void __init sparse_memory_present_with_active_regions(int nid)
>
>  yeah - 64-bit is different here and it's not affected by the problem
>  because there SECTION_SIZE_BITS is 27 (==128 MB chunks),
>  MAX_PHYSADDR_BITS is 40 (== 1 TB) - giving 8192 section map entries.
>  Once larger than 1 TB 64-bit x86 systems are created MAX_PHYSADDR_BITS
>  needs to be increased.

also 64 bit
early_node_map[10] active PFN ranges
    0:        0 ->      149
    0:      256 ->   917408
    0:  1048576 ->  8519680
    1:  8519680 -> 16908288
    2: 16908288 -> 25296896
    3: 25296896 -> 33685504
    4: 33685504 -> 42074112
    5: 42074112 -> 50462720
    6: 50462720 -> 58851328
    7: 58851328 -> 67239936

and 32 bit only has one entry
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->  1048576

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