Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we support or forbid TypedArrays backed by SharedArrayBuffer #6

Open
rbuckton opened this issue Feb 6, 2020 · 11 comments
Open

Comments

@rbuckton
Copy link
Collaborator

@rbuckton rbuckton commented Feb 6, 2020

The getRandomValues method in the Web Cryptography API does not specify whether a SharedArrayBuffer is permitted in its specification text. Per w3c/webcrypto#213 it seems that implementations forbid its use.

  • Should we also forbid use of SharedArrayBuffer?
  • If we allow SharedArrayBuffer, do we need to set any expectations around getRandomValues not being an atomic operation (i.e., other threads might see a partially written buffer)?
@annevk
Copy link
Member

@annevk annevk commented Feb 25, 2020

I suspect that would allow for creation of a high-resolution timer and would therefore need to be behind the cross-origin isolated flag (COOP+COEP) at least in some host environments.

@ckknight
Copy link

@ckknight ckknight commented Feb 28, 2020

Given that one could fill an ArrayBuffer with random data and then manually copy that data (in an atomic way, even) to a SharedArrayBuffer, then it seems like the safest default is to forbid SharedArrayBuffer. In the future, I could imagine a SharedArrayBuffer.fillRandom that may have different semantics where atomicity is controlled.

@vapier
Copy link

@vapier vapier commented Feb 28, 2020

Considering platforms might be able to mitigate the hrtimer attack (e.g. Chrome's site isolation), it seems wrong for the spec to ban. Leave it to the platform to decide whether it may be safely supported.

@annevk
Copy link
Member

@annevk annevk commented Feb 29, 2020

Chrome's site isolation is not sufficient mitigation and they also plan to migrate to a more restrictive environment: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes.

@vapier
Copy link

@vapier vapier commented Feb 29, 2020

So you agree that the spec shouldn't be banning it, but leaving it to implementations to decide whether & when it is supported.

@annevk
Copy link
Member

@annevk annevk commented Feb 29, 2020

I'm saying that if it's allowed there needs to be a hook for host environments that can indicate whether it's supported so it can plug into the cross-origin isolated flag in HTML, for instance.

@vapier
Copy link

@vapier vapier commented Feb 29, 2020

Sure, but that's an implementation consideration/problem, not something the spec needs to be mandating.

@annevk
Copy link
Member

@annevk annevk commented Mar 2, 2020

No it's not, it's a host problem and something the host needs to have a say over. I.e., it's a spec problem.

@vapier
Copy link

@vapier vapier commented Mar 3, 2020

I have no idea what you mean by "host". The spec is not a host.

Whether implementations are able to support shared buffers safely as a backend (or whether the concerns at hand are even relevant) is something only implementations can possibly know. The spec should not be forbidding behavior simply because some implementations (which don't even support SharedArrayBuffer now for webcrypto APIs) don't take into consideration all the factors.

@annevk
Copy link
Member

@annevk annevk commented Mar 3, 2020

https://tc39.es/ecma262/#sec-overview second sentence.

@vapier
Copy link

@vapier vapier commented Mar 3, 2020

The second sentence doesn't define "host" precisely. But the high level statement seems to agree with/match my points.

The only thing that knows whether shared array buffers may be used safely is the host environment, not the spec. Hence the spec should not be banning its usage.

Simply fix the spec to say that shared array buffers are permitted, but the host environment may block its usage, and then include a non-normative section giving examples of where that might come up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants