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:	Thu, 4 Feb 2010 17:51:33 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Oleg Kutkov <elenbert@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Fwd: Problem with set_memory_rw

On Thu, 4 Feb 2010 10:09:57 +0200
Oleg Kutkov <elenbert@...il.com> wrote:
> Thank for answer!
> But this is a very strange, because 0x0509940 - it a virtual memory
> address (i got it from System.map, this is a system call table, on my
> machine). set_memory_rw return zero, anyway. Maybe, system call table
> is much write protected, so i can't change attribute of memory page?
> One more interesting thing:
> 
> 
> 
> struct page *pg;
> pg = virt_to_page(addr);
> unsigned long page_addr;
> page_addr = (unsigned long) page_address(pg);
> 
> 
> addr - this is my virtual address (provided by System.map)
> But page_addr got another value!
> What wrong?
> Sorry, if my questions is to stupid.
> 

Below is only about virt_to_page() etc... (not about set_memory_rw())
Maybe my answer for set_memory_rw() was pointless.

I think system call table is on .rodata section and set_memory_rw() doesn't
allow change attributes on .rodata sections(not .text)
..I'm sorry if I'm wrong.

==
At first, Linux maps physical memory in linear mapping. virt_to_page(), 
page_address()..etc works for this linear mapping area.

AFAIK, in some arch?, kernel's text area is on outside of linear mapping area.

For example, ia64 has
  0xa00xxxxxxxxxxxxxxxxxx  for kernel text.
  0xe000xxxxxxxxxxxxxxxxx  for linear mapping.

Another example, x86 has
  0xffffffff80000000       for kernel text.
  0xffff880000000000       for linear mapping's base address.

I know base address of linear mapping area is represented as __PAGE_OFFSET
in many archs. please check.

Anyway, "what 0x0509940 is" depends on your arch. I think.
Maybe it's good to investigate how __pa() and __va() is implemented on your arch.


Thanks,
-Kame

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