On Tue, Oct 26, 2010 at 9:39 PM, Prabhu nath <gprabhunath@xxxxxxxxx> wrote: > Thanks a lot for the clarification. > Is that not a big hole that the kernel provides ?. If I have a root access, > then I can spoil the whole system. > Is there any motive for the kernel to support this ? /dev/mem or /dev/kmem is still present because of the legacy applications that still use it. In the old days, reading/writing any part of the system memory was done through /dev/kmem. For ex. instead of using /proc filesystem to interact with kernel, you can use /dev/kmem to interact with the kernel. Although, it is *okay* to use /dev/kmem for reading, it is a particularly bad idea to use it to write data into the kernel. That is because, if you want to change the value of a particular field in a kernel data structure for ex., you would find the offset of the object based on the kernel image & sometimes if you were not sure as to which particular kernel you booted, your offset will be wrong & you would trash a certain kernel data structure possibly bringing down the whole system. So, there should be no new applications that should use it though it is still present just for the sake of some legacy applications that haven't been adapted either because applications are no longer actively developed or may be because developers don't want to get away with /dev/kmem because of sheer power & simplicity it brings to the table albeit at the cost of stability of the entire system. Regards, Venkatram Tummala > > Thanks, > Prabhu > > > On Wed, Oct 27, 2010 at 10:04 AM, Dave Hylands <dhylands@xxxxxxxxx> wrote: >> >> Hi Prabhu, >> >> On Tue, Oct 26, 2010 at 9:19 PM, Prabhu nath <gprabhunath@xxxxxxxxx> >> wrote: >> > Dear All, >> > >> > Can you please clarify my doubt on /dev/mem >> > >> > When I open /dev/mem, Is that entire physical address space is >> > associated to /dev/mem or only the system memory ? >> > * If I can mmap the kernel memory in read write mode, I can >> > screw >> > up the whole kernel. Is that right ? >> >> Absolutely. >> >> > * Suppose I map a random memory page frame (let's assume it is >> > a >> > free page) from physical address 1abde000 to 1abdf000, >> > then will the page allocator not allocate this page to to any >> > other task or to the kernel ? >> >> Accessing through /dev/mem has no impact on the page allocator. >> >> Accessing memory through /dev/mem is the same thing as the kernel >> accessing that memory from within kernel space. You can access >> allocated pages, unallocated pages, device registers, pretty much >> anything at all. Writing indiscriminantly through /dev/mem is the same >> thing as writing indiscriminantly from within a driver. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ