555033 - make nanojit code cache read/execute only on Windows

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Robert Sayre]

Andreas:
> I wonder what the next steps are. Windows support? Should we try to settle on
> one mechanism together with Adobe?

Comment 1

[Robert Sayre]

Anyone on the CC list want to take this?

Comment 2

[Edwin Smith]

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.

Comment 3

[Andreas Gal :gal]

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.

Comment 4

[Andreas Gal :gal]

Attachment: sketch

Comment 5

[Andreas Gal :gal]

Attachment: patch

Be extra careful that we don't leak X pages back to the heap.

Comment 6

[Graydon Hoare :graydon]

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)

Comment 7

[Andreas Gal :gal]

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.

Comment 8

[Graydon Hoare :graydon]

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.

Comment 9

[Andreas Gal :gal]

This is won't fix for now, but might be re-opened.

Comment 10

[Robert Sayre]

fwiw, I don't see why we should follow the SELinux model on other platforms. The feedback on the SELinux approach is really bad.

Comment 11

[Andreas Gal :gal]

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.