On Mon, Dec 24, 2018 at 10:40 AM <[email protected]> wrote: > OSv can run unmodified Linux applications which are complied with `-fPIC` > or `-pie`. However, position dependent executables are not support. > > Currently, OSv kernel image is mapped at low address space (0x 20 0000). > Many position dependent executable executables also start at a low address, > such as 0x 40 0040. >
The ability to run one position-dependent executable was proposed in https://github.com/cloudius-systems/osv/issues/190 But so far nobody has done this, because it's usually quite easy to recompile as shared object, and because running a regular executable will come with strings attached: you can only run one of them (so you can't expect completely normal Linux packages, including shell scripts and other stuff, to just work out of the box), and you'll also have all the regular problems of PIE - see https://github.com/cloudius-systems/osv/issues/352 and https://github.com/cloudius-systems/osv/issues/689 (shared objects have more complete support). > > OSv Linear Address Space: > > > --------- 0x 0000 0000 0000 0000 > > | | > > --------- 0x 0000 0000 0020 0000 kernel_base --\ > > | | |- Kernel (Core ELF) > - 22M > > --------- 0x 0000 0000 0180 0000 lzkernel_base --/ > > | | > > |-------- 0x 0000 1000 0000 0000 program_base --\ > > | | |- s_program - 8G > > |-------| 0x 0000 1002 0000 0000 --\ --X > > | | |- Program | > > |-------| 0x 0000 1004 0000 0000 --/ | > > | | |- ELF Namespaces(max: > 32) - 256G > > | | ...................... | > > | | | > > |-------| 0x 0000 1042 0000 0000 --/ > > | | > > --------- 0x ffff 8000 0000 0000 phys_mem --\ > > | | |- Main Area - 16T > > --------- 0x ffff 9000 0000 0000 --X > > | | |- Page Area - 16T > > --------- 0x ffff a000 0000 0000 --X > > | | |- Mempool Area - 16T > > --------- 0x ffff b000 0000 0000 --X > > | | |- Debug Area - 80T > > --------- 0x ffff ffff ffff ffff --/ > > > > Linux Linear Address Space: > > --------- 0x 0000 0000 0000 0000 --\ > > | | |- Reserved (Catch Exceptions of > NULL/Little Pointers) > > --------- --X > > | | |- Text Segment > > --------- --X > > | | |- Data Segment > > --------- --X > > | | |- [Random] > > --------- --X > > | | |- Heap > > --------- --/ \/ > > | | > > --------- --\ > > | | |- Memory Mapping Segment > > --------- --/ > > | | |- [Random] > > --------- --/ > > | | > > --------- --\ /\ > > | | |- Stack > > --------- --X > > | | |- [Random] > > --------- --X > > | | |- Command-line Arguments > > --------- --X > > | | |- Environment Variables > > | | --/ > > --------- > > | | > > --------- 0x 0000 7fff ffff ffff > > | | > > | | -- Unused Space > > | | > > --------- 0x ffff 8000 0000 0000 --\ > > | | | > > | | |- Kernel Space - 128T > > | | | > > --------- 0x ffff ffff ffff ffff --/ > > > > If OSv kernel image can be mapped to high address space like Linux ( 0x > ffff 8000 0000 0000 ?), then low address space can be used for applications. > So, single position dependent executable can be supported like shared > objects and PIE. > > I have tried to do this, but it seems difficult for me. Can you give some > advice? > > I haven't tried to do this, or thought it through, but it should be possible. Right now in 0xfff.... we map the entire physical memory linearly, to return through malloc(). We can start this mapping in a slightly higher address, i.e., increase "phys_mem" and leave a lower range in 0xfff... for the other stuff - kernel, mmap(), and shared objects. We'll also need to change the loader to load the kernel to a different address. Nadav. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
