hello... > By higher I mean a virtual address greater than PAGE_OFFSET + <ram > size> From what I read, this value is kept in a variable called > high_memory (hence the term "higher memory", sorry if I was > ambiguous) Ok, I got it. I also cross check it on UTLK (Understanding The Linux kernel) and this variable is indeed pointing to last virtual address of the upper bound of RAM. > > Hm, interesting. In one side, high_memory denotes the end of the > > physical RAM mapping. At another side, high memory pool refers to > > page frame that can't fit inside kernel address space (above 896 > > MB). Wonder why it happens...anybody can explain? > > I don't know about the second meaning, but later you wrote that the > kernel maps at most 896M of RAM. Is it possible that both meaning you > mentioned are actually one? maybe...but I need to research it first. However, that 896 MB mark also depends on VM split. in 2G/2G split, you got another number. In 64 bit, thing is changing too, all RAM is directly addressable, thus there is no highmem pool. > > Hayim, can you explain why it is mapped twice? > > I don't remember my own example but I think the free frames were > those at physical addresses 0x0600 and 0x0800, and you allocated 8K > with vmalloc. Suppose vmalloc returned 0xC4801000. > So the virtual address 0xC4801000 is mapped to physical address > 0x0800, and 0xC4801200 is mapped to physical addr 0x600. > > Regaedless to this mapping the kernel maps the virtual address > 0xC0000600 to physical address 0x600, and 0xC0000800 to physical > address 0x800. > > Not that I think it is a wrong or impossible thing to do. Hmmmm, if something like this happen for user space, I can understand. But for kernel space? CMIIW, all those pages are actually inside same memory address space, that is kernel space. Thus, even kernel itself inside protected environment, IMHO kernel doesn't need to map a page reserved for kernel usage several times with different virtual address. Do I miss something here? > > IMHO, although the above address (0xC2100000) is in kernel address > > space, it doesn't neccesarily mean there is a page table that maps > > the page to that virtual address. Thus, unmapping the page is > > conditional. > > Please explain. When does the mapping from virtual 0xC2100000 to > physical 0x2100000 cease to exist? Whoops, looks like I got wrong understanding here. I ask some friends on #kernelnewbies IRC channel and it is confirmed that all the RAM pages are mapped into kernel space (of course, until the all available kernel address are take up, the rest are ). So, to be consistent with I am saying above, 0xC210000 to 0x2100000 doesn't exist if the RAM is less than or equal to 32 MB. Since you assume physical RAM is indeed 64MB, then the mapping must exist. Only one case cease it IMHO, that if the user boot the kernel by giving "mem=" a certain number below the real amount of installed RAM. Somebody..again, feel free to CMIIW... > I already asked Talib about it. He has some safe guards, not 100% > success but secure enough in his opinion. I hope it is really really secure, if not, those guys who usually write to Phrack will soon exploit it and make their exploit goes to metasploit project :) And soon, all those script kiddies will happily test it :)) > 2 cents??? > I'll take eight! OK, just give me that Uncle Bill, please ? :) regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
