Andreas: > I wonder what the next steps are. Windows support? Should we try to settle on > one mechanism together with Adobe?
Anyone on the CC list want to take this?
in Tamarin-redux, we use the CodeWriter api to mark pages RW while we are generating code, and RX when executing. This works on the major platforms, but might need a little more work for tracemonkey (where patching occurs more frequently). It has also produced controversy in bug 506693. I'd be happy to discuss options with someone from TM.
Ed and I have discussed this to death. It will involve a slowdown. I will confer with ed and either implement it myself or find some help.
Created attachment 434992 [details] [diff] [review] patch Be extra careful that we don't leak X pages back to the heap.
Isn't this sort of flipping between W and X exactly what the original bug was opened in order to eliminate? IOW, if you land this won't you be making SELinux cranky? (Not that I am any more warm to the proposed SELinux-appeasement plan than I was at first)
Both approach seem to be fatally flawed, however, both approach are improvements over everything writable everything executable in the code cache. This patch should work well for anything but SELinux, which disallows making an executable page ever writable again. Yes, if someone does a return-to-libc and mprotects away the write block, we are hosed, but that's no easy feat. We could use this for everything but SELinux, basically.
Yes. And my point is that this bug is blocking (presently) the bug that called "SELinux is preventing JIT from changing memory segment access". Which you are only exacerbating here, by doing it more. I am on your side as far as what I want us to do -- I think SELinux's needs here are being served in a silly way -- but I'm just pointing out the incongruity of this patch relative to the stated aims.
This is won't fix for now, but might be re-opened.
fwiw, I don't see why we should follow the SELinux model on other platforms. The feedback on the SELinux approach is really bad.
fwiw, I like neither approach. This approach here can be circumvented using a return-to-libc attack, undoing the protection. The SELinux spiel has writable code memory mapped somewhere, even if its not as easily accessible as it is right now. Shaver feels we can add this on top of the other patch, and he is probably right.