On 2016-10-31 at 15:55 "Ronald G. Minnich" <[email protected]> wrote: > + /* compute the end with the unaligned address and size. > + * Figure out the alignment for the start. > + * The size is the computed end minus the aligned start. */ > + end = h->p_paddr + h->p_memsz; > + align = h->p_align; > + start = h->p_paddr & ~(align-1); > + size = end - start;
this concerns me a little, and i think it's the source of your bug. i think we're not supposed to align-down start all the way, and doing so wastes a chunk of memory and causes other problems. https://sourceware.org/ml/binutils/2004-09/msg00166.html says: "it [elf spec] means p_offset mod p_align = p_vaddr mod p_align here's a linux guest i have sitting around: Program Header: LOAD off 0x0000000000200000 vaddr 0xffffffff81200000 paddr 0x0000000001200000 align 2**21 filesz 0x000000000021da88 memsz 0x000000000021e000 flags r-x LOAD off 0x000000000041e000 vaddr 0xffffffff8141e000 paddr 0x000000000141e000 align 2**21 filesz 0x0000000000051000 memsz 0x0000000000051000 flags rw- LOAD off 0x000000000046f000 vaddr 0xffffffff8146f000 paddr 0x000000000146f000 align 2**21 filesz 0x0000000000a9ff9d memsz 0x0000000000b1a000 flags rwx NOTE off 0x00000000003c857c vaddr 0xffffffff813c857c paddr 0x00000000013c857c align 2**2 filesz 0x0000000000000024 memsz 0x0000000000000024 flags --- for PH 2, we have : off 0x000000000041e000 vaddr 0xffffffff8141e000 paddr 0x000000000141e000 align 2**21 that align might just mean that the lower 21 bits should be the same between the addrs and the offset, which they are. i don't know if align is anything other than a 'should' in the spec. i didn't read it all. but i do see that we need to page align start and end. so given a non-page aligned paddr (since its the kernel), we'd need to rounddown, and likewise roundup the memsize, being careful of the ends, etc. here's the potential problem. say you were loading these three sections, your current code with its align stuff would do this: 0x0000000001200000 -> mmap [0x1200000 - 0x141e000) 0x000000000141e000 -> mmap [0x1400000 - 0x146f000) 0x000000000146f000 -> mmap [0x1400000 - 0x1f89000) my math might be off with that a little. the main idea though is that each section clobbers some of the previous one, due to the align down to 2**21. the MAP_FIXED will mmap it exactly there, no questions asked, and the previous stuff will probably be unmapped and freed. that previous stuff is the contents of the file that you read in. anyway, that seems like a problem. i'd try just enforcing (or asserting, my favorite!) page aligned segments and ROUNDUP() the size to mmap() to PGSIZE. barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
