On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote: > 2012/10/6 PaX Team <pagee...@freemail.hu>: > > sadly, this is not true at all, for multiple reasons: > > > .. snip ... > > > > cheers, > > PaX Team > > > > So can I summarize your position as that there is no merit at all in > the ability to inhibit future permissions of existing mappings?
i believe i answered this in the previous mail already: > there's certainly a point (i've been doing it for 12 years now), but to > make an mprotect flag into an actual security feature, it had better pass > simple tests, such as non-circumventability. any method relying on > userland playing nice is already suspect of being the wrong way and right > now i don't see how PROT_FINAL could be used for actual security. so if PROT_FINAL wants to be useful, you'd have to present a case of how it does something useful *while* an exploited userland cannot get around it. in fact i think i already told you that presenting your own use case in more detail (read: source code, policy, etc) would be a great step in 'selling the idea'. the fact that you seem to be reluctant to follow up on this leaves me somewhat uneasy as it may be the sign of a proprietary vendor's trying to push some code into mainline that nobody else has a clear idea how it'd benefit the rest of us. you see, you're asking for a change in a system call, which is a very important boundary for kernel developers as they'll have to maintain it indefinitely. so the burden is on you to prove that either this is the only way to implement a useful feature or at least it is the optimal way as opposed to other approaches. i suggested you ways to both attack the initially presented concept and also how it may be improved, but i got no answers to them yet. cheers, PaX Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/