On Mon, Jan 23, 2017 at 2:48 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > >> This is not easy at all, but: how about rewriting execve() so that the >> actual binary format parsers run in user mode? > > Sounds very chicken-and-egg-ish. Issues you'd have: > > (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. > > (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. > > (3) How do you deal with address randomisation? Non-issue, I think. > > (4) You may have to start without a stack as the kernel wouldn't necessarily > know where to put it or how big it should be (see 6). Or you might have > to relocate it, including all the pointers it contains. The relocation part is indeed a bit nasty. > > (5) Where should the kernel put arguments, environment and other parameters? > Currently, this presumes a stack, but see (4). Hmm. > > (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. > > (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. Anyway, I didn't say this would be easy :) > >> A minor one for x86: give binaries a way to opt out of the x86_64 >> vsyscall page. I already did the hard part (in a branch), so all >> that's really left is figuring out the ABI. > > munmap() it in the loader? Hmm, *that's* an interesting thought. You can't remove the VMA (it's not a VMA) but maybe munmap() could be made to work anyway. Hey mm folks, just how weird would it be to let arch code special-case unmapping of the gate pseudo-vma? --Andy -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
