Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability
Hey folks, We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time spec <https://w3c.github.io/hr-time/> to better align its resolution clamping with cross-origin isolated capability <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability>, and now I'm interested in shipping this change in Chromium. In practice that means that Chromium would be reducing its resolution in non-isolated contexts (regardless of the platform's site-isolation status) to 100 microseconds, and increasing it in cross-origin isolated contexts (even in platforms without site-isolation, e.g. Android) to 5 microseconds. As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your position on the latter. Would y'all be interested in increasing timer granularity in contexts which have guarantees against pulling in cross-origin resources without their opt-in? I'd appreciate your thoughts on the matter. Cheers :) Yoav
For the 100 microsecond value — our research suggests that you need a much higher value in vulnerable contexts. For the guaranteed isolated case — have you considered the use of high precision time to carry out non-Spectre timing attacks? Thanks, Geoff
On Mar 17, 2021, at 3:38 AM, Yoav Weiss via webkit-dev <webkit-dev@lists.webkit.org> wrote:
Hey folks,
We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time spec <https://w3c.github.io/hr-time/> to better align its resolution clamping with cross-origin isolated capability <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability>, and now I'm interested in shipping this change in Chromium. In practice that means that Chromium would be reducing its resolution in non-isolated contexts (regardless of the platform's site-isolation status) to 100 microseconds, and increasing it in cross-origin isolated contexts (even in platforms without site-isolation, e.g. Android) to 5 microseconds.
As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your position on the latter. Would y'all be interested in increasing timer granularity in contexts which have guarantees against pulling in cross-origin resources without their opt-in?
I'd appreciate your thoughts on the matter.
Cheers :) Yoav _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Wed, Mar 17, 2021 at 5:51 PM Geoff Garen <ggaren@apple.com> wrote:
For the 100 microsecond value — our research suggests that you need a much higher value in vulnerable contexts.
For the guaranteed isolated case — have you considered the use of high precision time to carry out non-Spectre timing attacks?
Could you elaborate on those 2 points?
Thanks, Geoff
On Mar 17, 2021, at 3:38 AM, Yoav Weiss via webkit-dev < webkit-dev@lists.webkit.org> wrote:
Hey folks,
We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time spec <https://w3c.github.io/hr-time/> to better align its resolution clamping with cross-origin isolated capability <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability>, and now I'm interested in shipping this change in Chromium. In practice that means that Chromium would be reducing its resolution in non-isolated contexts (regardless of the platform's site-isolation status) to 100 microseconds, and increasing it in cross-origin isolated contexts (even in platforms without site-isolation, e.g. Android) to 5 microseconds.
As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your position on the latter. Would y'all be interested in increasing timer granularity in contexts which have guarantees against pulling in cross-origin resources without their opt-in?
I'd appreciate your thoughts on the matter.
Cheers :) Yoav _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu, Mar 18, 2021 at 12:26 AM Yoav Weiss via webkit-dev <webkit-dev@lists.webkit.org> wrote:
On Wed, Mar 17, 2021 at 5:51 PM Geoff Garen <ggaren@apple.com> wrote:
For the 100 microsecond value — our research suggests that you need a much higher value in vulnerable contexts.
For the guaranteed isolated case — have you considered the use of high precision time to carry out non-Spectre timing attacks?
Could you elaborate on those 2 points?
We've made a conclusion, based on our prior research, that in order to successfully mitigate Spectre / Meltdown class of attacks, we can't allow 100μs precision timing measurements. As such, we have no plan or desire to increase the precision of "high precision" time from 1ms to 100μs. I'm not going to provide details as to how or why due to the nature of the topic. The second point is that there are dangerous timing attacks besides from Spectre/Meltdown that are effective with a precision meaningfully higher than 100μs. This is why the precision of WebKit's high resolution time had been reduced to 100μs in https://trac.webkit.org/r209462 even prior to the issue of Spectre / Meltdown were identified. There are a number of literatures on various kinds of timing attacks possible, but again, I'd refrain from disclosing details here. - R. Niwa
participants (3)
-
Geoff Garen
-
Ryosuke Niwa
-
Yoav Weiss