Thread: Kernel bug? (attn matsp)

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Registered User
    Join Date
    Oct 2007
    Posts
    32
    Quote Originally Posted by brewbuck View Post
    Yep! I finally realized this. I was also having some trouble with position-independence -- using -fPIC doesn't work, because it causes inter-module function dispatch to go through the PLT. But the PLT is useless because I'm the dynamic linker and I have nobody to set it up for me

    So I ended up using -fpie instead, linked with -shared, and now all is well.

    I still think the call to exec() should fail if the program interpretter would be mapped over the top of the ELF image. That's just dumb.
    Neither kernel nor user space never prevent you from shouting yourself.
    rm -rf / is sure worse then your case, but still kernel doesn't prevent it.

    And even if it did - I don't think you was better off with execve failed with EINVAL than you are now.

    mmap with MMAP_FIXED flag set also will happily overwrite already mapped memory.

    By the way, why you need your own dynamic linker ?
    What did you miss in the standard one ?

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Valery Reznic View Post
    Neither kernel nor user space never prevent you from shouting yourself.
    rm -rf / is sure worse then your case, but still kernel doesn't prevent it.
    A person could conceivably want to do "rm -rf /". But it makes no sense to EVER map the interpreter on top of the program image. Without the image, there is nothing for the interpreter to do. It's a scenario that makes no sense.

    And even if it did - I don't think you was better off with execve failed with EINVAL than you are now.
    I would have been able to diagnose my problem much faster.

    mmap with MMAP_FIXED flag set also will happily overwrite already mapped memory.
    That's a design flaw. You should be required to deliberately unmap the region first before mapping something else there (or at least specify a flag indicating your intention, i.e. MAP_REPLACE). Again, it leaves the door open for massive confusion when things can silently map on top of other things when that is not the intention.

    By the way, why you need your own dynamic linker ?
    What did you miss in the standard one ?
    If I can implement a dynamic linker, then I know I understand how ELF dynamic linking works in the minutest detail.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Oct 2007
    Posts
    32
    Quote Originally Posted by brewbuck View Post
    A person could conceivably want to do "rm -rf /". But it makes no sense to EVER map the interpreter on top of the program image. Without the image, there is nothing for the interpreter to do. It's a scenario that makes no sense.
    I still can't see how "rm -rf /" make sense.
    But the point is - kernel usually not held your hand. It provides services and
    left to user space to make sense of it.

    And I think usually it's a good thing.


    That's a design flaw. You should be required to deliberately unmap the region first before mapping something else there (or at least specify a flag indicating your intention, i.e. MAP_REPLACE). Again, it leaves the door open for massive confusion when things can silently map on top of other things when that is not the intention.
    Agree. But I think this behavior required by POSIX, so no hope to that change :(



    If I can implement a dynamic linker, then I know I understand how ELF dynamic linking works in the minutest detail.
    I want someday to do it too. But that day is still a long way away :)

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Valery Reznic View Post
    I still can't see how "rm -rf /" make sense.
    One realistic scenario would be a program which is launched inside a chroot environment, which wipes its local root when done doing whatever it's doing...

    Agree. But I think this behavior required by POSIX, so no hope to that change
    Yeah... Standards are good and bad. Linux could maintain compatibility by using a MAP_NOREPLACE flag, since not using this flag would not change the behavior. Of course, users would have to remember to use it. But simply the existence of such a flag would entail some language in the documentation, which might have clued me in to my mistake a lot sooner...
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Kernel building error
    By nsayag in forum Linux Programming
    Replies: 8
    Last Post: 07-15-2009, 06:04 PM
  2. SOS - Can a monolithic kernel be used in a micro-kernel style OS?
    By sean in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 11-20-2008, 09:30 AM
  3. ATL bug of CComPtr?
    By George2 in forum Windows Programming
    Replies: 6
    Last Post: 04-07-2008, 07:52 AM
  4. Programming RIP2 with kernel routes table
    By jpablo in forum Linux Programming
    Replies: 1
    Last Post: 04-22-2006, 11:26 AM
  5. CreateThread ?!
    By Devil Panther in forum Windows Programming
    Replies: 13
    Last Post: 11-15-2005, 10:55 AM