Re: [Ksummit-discuss] security-related TODO items?

[David Howells <dhowells@redhat.com>]

Andy Lutomirski <luto@amacapital.net> 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.

 (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.

 (3) How do you deal with address randomisation?

 (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.

 (5) Where should the kernel put arguments, environment and other parameters?
     Currently, this presumes a stack, but see (4).

 (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.

 (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.

> 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?

David