Re: Executing from readablee, no-exec pages

As revealed by the recent "Prevent data exception in kernel
space" patch, versions of glibc prior to 2.4[1] assume that,

Are you sure that this hasn't been fixed somewhere in the 2.3
series, too?

on powerpc32, they can execute out of any readable mapping,
regardless of whether it is marked for execution.  This happens
in the elf_machine_load_address() function.

To maintain compatibility with these versions, we could change
the test in do_page_fault() to include VM_READ as well as VM_EXEC
on targets that don't have a separate exec-bit in hardware (are
there any powerpc mmus that do?).  However, Segher suggested on
IRC that we may want to drop compatibility with those old versions
of glibc, and that I should seek your input.

"drop compatibility" -- this sounds worse than it is, this is all
about supporting a badly broken application.

I wonder how this works with 32-bit userland on a 64-bit kernel,
or with older kernels.  With arch/ppc/ an exec fault would do
the read checks IIRC, maybe we need to change to that.

Personally, I'd rather stick the VM_READ in there, partially for
selfish reasons (our root filesystems are based on older glibcs),
and because it seems a little too soon to deprecate glibc 2.3,

Oh I don't know, can't we just deprecate glibc completely?  ;-)

but also because in the absence of hardware support, the VM_EXEC
check will be nondeterministic, kicking in only when the first
fault for a page is to execute.

I don't think that is a big concern.

[1] It's possible that there are other instances of this in 2.4 and  
that the actual version is newer; I ran into obnoxious cross  
compilation issues trying to try it.  However,

<rant>"Trying to try it" sounds like compiling glibc, indeed.</rant>

<rant>
Glibc already has target-specific code/headers; if you need to know  
something that you'd otherwise need a runs-on-the-target autoconf  
test for, why not just stick it in such a target-specific header?   
In this case, it was trying to figure out the size of "long double".
</rant>

You can do a test like this by cross-compiling some code, and looking
at the size of the symbol in the resulting object file.  Well that's
all off-topic here.


Segher