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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 04 Feb 2013 15:24:45 +0900
From:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To:	ralf@...ux-mips.org, michael@...erman.id.au,
	benh@...nel.crashing.org, paulus@...ba.org,
	holzheu@...ux.vnet.ibm.com, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com, vgoyal@...ibm.com
Cc:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] kdump: make saved_max_pfn exlusive

First, there are two kinds of notation to represent a map: inclusive
and exclusive. Here are the examples:
    
  1)  [mem 0x0000000100000000-0x000000013fffffff]
  2)  [mem 0x0000000100000000-0x0000000140000000]
    
1) is inclusive and 2) is exclusive. In case of 1), the pfn calculated
from the end address belongs to the map, while in case of 2), it
doesn't.

Currently, saved_max_pfn is used in read_oldmem() as inclusive for a
check to see if a given request is to within kernel's memory mapping
regions.
    
	while (count) {
		pfn = *ppos / PAGE_SIZE;
		if (pfn > saved_max_pfn)
		   	return read;
    
Unfortunately, on x86 and ia64, there are bugs below:
    
- On the 1st kernel, saved_max_pfn is not initialized so 0. Then, read
  to pfn 0 is not guarded by the condition and the execution goes into
  ioremap path.
    
- On the 2nd kernel, x86 and ia64 wrongly initializes saved_max_pfn by
  exclusive value, on x86 as:
    
	saved_max_pfn = e820_end_of_ram_pfn();
    
  by which via /dev/oldmem we can read max_pfn that is not kernel's
  memory.
    
To fix this, fixing x86 and ia64 part needs smaller change, but
max_pfn is originally treated as exclusive so saved_max_pfn should
normally be exclusive. Also, the memory map information passed from
kexec is all exclusive on every architectures; it's possible to make
saved_max_pfn exclusive now.

However, ppc and ppc64 on kexec doesn't increment end address now and
this should be done as an insurance when map passed from firmware is
inclusive, for which I'll post a patch later.

---

HATAYAMA Daisuke (4):
      kdump, oldmem: compare with saved_max_pfn exclusively
      kdump, s390: make saved_max_pfn exclusive
      kdump, ppc: make saved_max_pfn exclusive
      kdump, mips: make saved_max_pfn exclusive


 arch/mips/kernel/crash_dump.c    |    2 +-
 arch/powerpc/kernel/crash_dump.c |    2 +-
 arch/s390/kernel/setup.c         |    4 ++--
 drivers/char/mem.c               |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 

Thanks.
HATAYAMA, Daisuke
--
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