Bug 181453 - Spectre bound check mitigation efficiency
Summary: Spectre bound check mitigation efficiency
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-09 15:12 PST by dougc
Modified: 2018-01-09 19:18 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dougc 2018-01-09 15:12:34 PST
Although some mitigations for the Spectre vulnerabilities have been deployed, for example https://bugs.webkit.org/show_bug.cgi?id=181313, I would like to suggest one alternative strategy that does not appear to have been explored, might need feedback from Intel etc who have not responded to me personally. The idea is to create a data flow dependency on the array length so that the protected memory access can not execute until the same time that the speculative bounds check branch can execute. Tests suggests this is faster than the index masking approaches that are added to the bounds check. Please see https://weblll.org/index.php/spectre-bounds-check-data-flow-mitigation/
Comment 1 Filip Pizlo 2018-01-09 19:02:43 PST
This doesn’t completely fix Spectre since the CPU will sometimes verify the branch after the leaking load. There is nothing in your code snippet that prevents this. 

So, although this probably performs great, it’s too risky since it still leaves Spectre as a theoretical possibility.
Comment 2 dougc 2018-01-09 19:18:12 PST
> This doesn’t completely fix Spectre since the CPU will sometimes verify the branch after the leaking load. There is nothing in your code snippet that prevents this. 

Yes that is a possibility, but to me an unknown. Did you get some confirmation from Intel etc on this, or is it just that this in an unknown?

If it has to be masking, or other data flow strategies to limit the index, then so be it, but just wanted to be sure.