Executing from readablee, no-exec pages

[Segher Boessenkool]

> 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