On 10/10/2014 08:14 PM, Baoquan He wrote:
On 10/08/14 at 03:27pm, Vivek Goyal wrote:
On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
Sorry... this makes no sense.
For x86-64, there is no direct connection between the physical and
virtual address spaces that the kernel runs in...
I am sorry I did not understand this one. I thought that initial
relocatable kernel implementaion did not have any direct connection
between virtual and physical address. One could load kernel anywhere
and kernel virtual address will not change and we will just adjust
page tables to map virtual address to right physical address.
Now handle_relocation() stuff seems to introduce a close coupling
between physical and virtual address. So if kernel shifts by 16MB
in physical address space, then it will shift by equal amount
in virtual address space. So there seems to be a direct connection
between virtual and physical address space in this case.
Yeah, it's exactly as Vivek said.
Before kaslr was introduced, x86_64 kernel can be put anywhere, and
always _text is 0xffffffff81000000. Meanwhile phys_base contains the
offset between the compiled addr (namely 0x1000000) and kernel loaded
addr. After kaslr implementation was added, as long as kernel loaded
addr is different 0x1000000, it will call handle_relocations(). The
offset now is added onto each symbols including _text and phys_base
becomes 0.
It's clearly showing that by checking /proc/kallsyms and value of
phys_base.
This really shouldn't have happened this way on x86-64. It has to
happen this way on i386, but I worry that this may be a serious
misdesign in kaslr on x86-64. I'm also wondering if there is any other
fallout of this?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html