On Sun, 4 May 2003, Yoav Weiss wrote:
> I don't see how the case of mprotect(HIGH_ADDRESS, LEN, PROT_EXEC) be
> handled. Unlike mremap, mprotect doesn't offer a way to inform the user
> about a change of address.
>
> If I understand correctly, such case will cause a call to
> arch_add_exec_range(current->mm, vma) without any remapping, thus
> breaking the protection.
yes - the patch does not put any limit on which areas can be PROT_EXEC -
if the executable area is 'too wide' then there's no protection. The patch
tries to relocate areas which are freely relocatable, to make sure that in
the usual case the exec-limit will be quite low.
> One case where this would happen is some of the ancient loaders. IIRC,
> libc4's loader did just that. (right, nobody uses it anymore :)
yeah, we should not be worried about old loaders.
> For that reason, maybe X_workaround should be controlled per-executable
> by another ELF flag and not as a system-wide property.
i'll remove X_workaround from the next patch altogether - X can be fixed
by enabling an executable stack for the binary.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:19 EST