Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > (1) You'd need at least one pre-loader binary image built into the kernel > > that you can map into userspace (you can't upcall to userspace to go get > > it for your core binfmt). This could appear as, say, /proc/preloader, > > for the kernel to open and mmap. > > No need for it to be visible at all. I'm imagining the kernel making > a fresh mm_struct, directly mapping some text, running that text, and > then using the result as the mm_struct after execve. What would you see in /proc/pid/maps? > > (2) Where would the kernel put the executable image? It would have to > > parse the binary to find out where not to put it - otherwise the code > > might have to relocate itself. > > In vmlinux. You misunderstood the question. I meant at what address would you map it into userspace? You would have to avoid anywhere the executable needs to place something - though as long as you can manage to start the loader, you can ditch the pre-loader, so that might not be a problem. > > (6) NOMMU could be particularly tricky. For ELF-FDPIC at least, the stack > > size is set in the binary. OTOH, you wouldn't have to relocate the > > pre-loader - you'd just mmap it MAP_PRIVATE and execute in place. > > For nommu, forget about it. Why? If you do that, you have to have bimodal binfmts. Note that the ELF-FDPIC binfmt, at least, can be used for both MMU and NOMMU environments. This may also be true of FLAT. > > (7) When the kernel finds it's dealing with a script, it goes back through > > the security calculation procedure again to deal with the interpreter. > > The security calculation isn't what I'm worried about. I'm worried > about the parser. But you may have to redo the security calculation *after* doing the parsing. > Anyway, I didn't say this would be easy :) True... :-) David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
