* Problem with set_memory_rw @ 2010-02-04 5:26 Oleg Kutkov 2010-02-04 5:45 ` KAMEZAWA Hiroyuki 0 siblings, 1 reply; 5+ messages in thread From: Oleg Kutkov @ 2010-02-04 5:26 UTC (permalink / raw) To: linux-kernel Hello, this is my first post in a mailing list, so excuse me if something wrong... I'm new in kernel and try to do some manipulation with memory pages. For manipulating memory page attributes i used set_memory_rw(), but function returning 0 and i can't continue writing to memory, because page, that i want to change, is read only by default. This is part of my code: long unsigned addr; addr = 0x0509940; //this is addres in memory, that i want to overwrite (read only, for default) set_memory_rw(addr, 1); //try to set rw permission on this addres for one memory page. So, function return zero, this is error, as i can understand. If i try to write by this address - kernel write in log error messages, such as "Unable to handle kernel request at address 0x0509940". This is kernel bug or something wrong in my code? Thank for any help. Best regards, Oleg. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with set_memory_rw 2010-02-04 5:26 Problem with set_memory_rw Oleg Kutkov @ 2010-02-04 5:45 ` KAMEZAWA Hiroyuki [not found] ` <5e9821061002040006p258c2738y87a26c769c04bcfd@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: KAMEZAWA Hiroyuki @ 2010-02-04 5:45 UTC (permalink / raw) To: Oleg Kutkov; +Cc: linux-kernel On Thu, 04 Feb 2010 07:26:25 +0200 Oleg Kutkov <elenbert@gmail.com> wrote: > Hello, this is my first post in a mailing list, so excuse me if > something wrong... > I'm new in kernel and try to do some manipulation with memory pages. > For manipulating memory page attributes i used set_memory_rw(), > but function returning 0 and i can't continue writing to memory, > because page, that i want to change, is read only by default. > This is part of my code: > > > long unsigned addr; > > addr = 0x0509940; //this is addres in memory, that i want > to overwrite (read only, for default) > > set_memory_rw(addr, 1); //try to set rw permission on this addres for > one memory page. > > > So, function return zero, this is error, as i can understand. If i try > to write by this address - kernel write in log error messages, such as > "Unable to handle kernel request at address 0x0509940". > This is kernel bug or something wrong in my code? > > Thank for any help. > set_memory_rw()'s 1st argument requires virtual address. So, you need virtual address of the page you want. - phys_to_virt() ... convert physical address to virtual address. - virt_to_phys() ... convert virtual address to physical. Anyway, RW is vitual address mapping's attribute and not for physical. Thanks, -Kame ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <5e9821061002040006p258c2738y87a26c769c04bcfd@mail.gmail.com>]
* Fwd: Problem with set_memory_rw [not found] ` <5e9821061002040006p258c2738y87a26c769c04bcfd@mail.gmail.com> @ 2010-02-04 8:09 ` Oleg Kutkov 2010-02-04 8:51 ` KAMEZAWA Hiroyuki 0 siblings, 1 reply; 5+ messages in thread From: Oleg Kutkov @ 2010-02-04 8:09 UTC (permalink / raw) To: linux-kernel set_memory_rw()'s 1st argument requires virtual address. So, you need virtual address of the page you want. - phys_to_virt() ... convert physical address to virtual address. - virt_to_phys() ... convert virtual address to physical. Anyway, RW is vitual address mapping's attribute and not for physical. Thanks, -Kame 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. P.S. I know, that overwriting system call table is very bad, i just experimenting with my own network drivers and i need to replace some network system calls.. Best regard, Oleg. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Problem with set_memory_rw 2010-02-04 8:09 ` Fwd: " Oleg Kutkov @ 2010-02-04 8:51 ` KAMEZAWA Hiroyuki 2010-02-04 9:12 ` Nick Piggin 0 siblings, 1 reply; 5+ messages in thread From: KAMEZAWA Hiroyuki @ 2010-02-04 8:51 UTC (permalink / raw) To: Oleg Kutkov; +Cc: linux-kernel On Thu, 4 Feb 2010 10:09:57 +0200 Oleg Kutkov <elenbert@gmail.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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: Problem with set_memory_rw 2010-02-04 8:51 ` KAMEZAWA Hiroyuki @ 2010-02-04 9:12 ` Nick Piggin 0 siblings, 0 replies; 5+ messages in thread From: Nick Piggin @ 2010-02-04 9:12 UTC (permalink / raw) To: KAMEZAWA Hiroyuki; +Cc: Oleg Kutkov, linux-kernel On Thu, Feb 04, 2010 at 05:51:33PM +0900, KAMEZAWA Hiroyuki wrote: > On Thu, 4 Feb 2010 10:09:57 +0200 > Oleg Kutkov <elenbert@gmail.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. You are right. static_protections() forbids rodata from being marked RW. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-02-04 9:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-04 5:26 Problem with set_memory_rw Oleg Kutkov
2010-02-04 5:45 ` KAMEZAWA Hiroyuki
[not found] ` <5e9821061002040006p258c2738y87a26c769c04bcfd@mail.gmail.com>
2010-02-04 8:09 ` Fwd: " Oleg Kutkov
2010-02-04 8:51 ` KAMEZAWA Hiroyuki
2010-02-04 9:12 ` Nick Piggin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox