Should we support or forbid TypedArrays backed by SharedArrayBuffer

tc39 / proposal-csprng

Cryptographically Secure Random Number Generation for ECMAScript

BSD 3-Clause "New" or "Revised" License

70 stars 9 forks source link

Should we support or forbid TypedArrays backed by SharedArrayBuffer #6

Open rbuckton opened 4 years ago

rbuckton commented 4 years ago

The getRandomValues method in the Web Cryptography API does not specify whether a SharedArrayBuffer is permitted in its specification text. Per https://github.com/w3c/webcrypto/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

annevk commented 4 years ago

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 commented 4 years ago

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

annevk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

vapier commented 4 years ago

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.