[Webkit-unassigned] [Bug 109836] [JIT] Memory overwrite by Math object functions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 25 09:22:26 PDT 2013


https://bugs.webkit.org/show_bug.cgi?id=109836





--- Comment #6 from Filip Pizlo <fpizlo at apple.com>  2013-03-25 09:24:54 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > This looks wrong; you seem to be jumping over the pops.  This will leave the stack in a weird state.
> > 
> > I'm not sure if this is a real bug, either.  It ought to be safe to store at a negative stack offset, in most platforms.
> > 
> > Plus, I don't like the implications for performance of the thunk: you're doing some extra pushes and pops.
> > 
> > But if it's a real bug, you could have implemented this by changing the offset at which we store the double.  The JITStackFrame::args should be reusable here, since we're not in the middle of a JITStub call.
> 
> Indeed I've made a mistake in pop/jump order that obscures the idea. Sorry for that. 
> But in general I was wondering if there is any chance that after many software and hardware optimizations on CPU cache L1/L2 level (where SP could be used as a reference of "untouched" memory after it) the memory located just after stack pointer in CPU cache could be used for a completely different memory page - what would be reason of seriously bug.
> Please keep in mind that the patch isn't prepared for merge. It only serves to bare the problem.

http://en.wikipedia.org/wiki/Red_zone_(computing)

It is safe to modify at least 8 bytes (and as much as 128 on x86_64) beyond the stack pointer without messing with the stack pointer itself. 

Nite that if the 8 bytes beyond the stack were on a different page then either that page is already reserved for the stack (in which case we're fine) or its not - in which case anything we try to do will overflow the stack and crash the program. Calling Math.floor is the least of our worries if the JITStackFrame is at the extreme bottom of the stack and we're about to run out.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list