Bugzilla

(In reply to Nicolas B. Pierron [:nbp] from comment #16)
> The issue is that the instruction cache might be stale, and that one attacker might use the stale content of the instruction cache as a mean to do random code execution, as the new code provide potentially a new entry point into a random position of code which was properly freed. However, being able to make use of this attack implies that the instruction cache was not trashed by all the code present in the rest of SpiderMonkey/Firefox which sounds very unliekly.

In addition to the i-cache needing to not be trashed, as stated above we have other reasons to think that our synchronization is sufficient for real hardware and this commit is just trying to be conservative for if there is something we have missed and to workaround the simulator. So the sec-low rating is to just be extra careful. The test was included so that we didn't have to circle back.

> The above linked two bugs show the reasons we have for thinking that our existing synchronization is sufficient for real hardware, and AFAICS are still valid. But just in the case that we are missing something, this commit adds an extra sync point to work around this debug assertion and to conservatively cover misbehaving hardware.

(In reply to Nicolas B. Pierron [:nbp] from comment #16)
> The issue is that the instruction cache might be stale, and that one attacker might use the stale content of the instruction cache as a mean to do random code execution, as the new code provide potentially a new entry point into a random position of code which was properly freed. However, being able to make use of this attack implies that the instruction cache was not trashed by all the code present in the rest of SpiderMonkey/Firefox which sounds very unliekly.

In addition to the i-cache needing to not be trashed, as stated above we have other reasons to think that our synchronization is sufficient for real hardware and this commit is just trying to be conservative for if there is something we have missed and to workaround the simulator. So the sec-low rating is to just be extra careful. The test was included so that we didn't have to circle back. It only triggers an assertion failure in the simulator, no failure happens on real hardware.

> The above linked two bugs show the reasons we have for thinking that our existing synchronization is sufficient for real hardware, and AFAICS are still valid. But just in the case that we are missing something, this commit adds an extra sync point to work around this debug assertion and to conservatively cover misbehaving hardware.