make nanojit code cache read/execute only on Windows

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
7 years ago
3 years ago

People

(Reporter: Robert Sayre, Assigned: gal)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Updated

7 years ago
Blocks: 506693
(Reporter)

Updated

7 years ago
OS: Mac OS X → Windows 7
(Reporter)

Comment 1

7 years ago
Anyone on the CC list want to take this?

Comment 2

7 years ago
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.
(Assignee)

Comment 3

7 years ago
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.
(Assignee)

Updated

7 years ago
Assignee: general → gal
(Assignee)

Comment 4

7 years ago
Created attachment 434986 [details] [diff] [review]
sketch
(Assignee)

Comment 5

7 years ago
Created attachment 434992 [details] [diff] [review]
patch

Be extra careful that we don't leak X pages back to the heap.
Attachment #434986 - Attachment is obsolete: true
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)
(Assignee)

Comment 7

7 years ago
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.
(Assignee)

Comment 9

7 years ago
This is won't fix for now, but might be re-opened.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 10

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

Comment 11

7 years ago
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.
You need to log in before you can comment on or make changes to this bug.