Should ECMAScript implementations be allowed to canonicalize NaN when writing into an Array?

[littledan]

V8 has several representations of Arrays based on different kinds of unboxed content, called ElementKind. One ElementKind is FAST_HOLEY_DOUBLE_ELEMENTS. With this kind, the Array may contain holes (missing properties which delegate to the prototype), but all non-hole elements are unboxed doubles (Numbers). The trick is to canonicalize NaNs when written into such an array, and use a particular NaN value for "the hole" to indicate that a lookup on the prototype is needed.

This implementation technique violates the ECMAScript specification because, in SetValueInBuffer, there is the following text:

An implementation must always choose the same encoding for each implementation distinguishable NaN value.

I believe this text was written with the intent of creating the cross-cutting effect that NaNs should always carry around their payload, and only get a new payload when a "new" NaN is created. (We could use some better spec text here to back that intention with more clear mechanics, and I've promised to do that, except I want to get this other issue worked out first.) A big piece of motivation for that is to prevent information leaks, e.g., in writing properties to frozen objects.

I'm wondering, is there a way that we could weaken this requirement? V8's practice of canonicalizing NaNs just in order to write them into certain objects seems to improve our performance, and it seems harmless to me, as I don't know of any information leaks that we're creating.

For a strawman: what if we simply removed that sentence and let SetValueInBuffer write whatever NaN representation it felt like? Is there another way we could convince ourselves that information leaks won't happen?

cc @bakkot @anba @erights @leobalter @verwaest

[ljharb]

-1 from me - the fewer places we allow differentiable NaN values, the better.

However, I think this ties into the last meeting's discussion where we wanted, instead of the current situation, to enumerate exactly where implementations must canonicalize, and then let the rest remain unspecified?

[erights]

and then let the rest remain unspecified

This was not the outcome of the last tc39 mtg, and would not have addressed the information leak concern. The concern is the leakage of implementation choices creating an exploitable side channel that others can use to communicate information. The more choices are left to the implementation, the greater the danger of this side channel.

In particular, the opaque passing around of a value --- loading, storing, passing as argument, etc... --- should not cause the value to be visibly mutated. This is the assumption that pervades coding practice. No one thinks "If I store this value in variable x and then read it from variable x, it might be different." Certainly, no one is prepared to defensive code against that possibility. If attacker A causes defender B to engage in one load/store pattern vs another before defender B passes that same value to collaborator C, then C can tell which way A provoked B.

[littledan]

@ljharb Yes, it does tie into that. I was suggesting to formalize what I felt to be the current intention for spec semantics (where the wording isn't so consistent right now), but then it turned out that these are too restrictive to describe V8's behavior. I want to figure this issue out first because it changes how we'd go about clearing up the spec.

The upside of making NaN canonicalization more weakly specified is that it gives implementations more flexibility to optimize. Fast holey double arrays are really useful for cases where you call the Array constructor with a length and then write all Numbers into it. At the same time, not doing NaN boxing saves memory for pointers.

The downsides are mostly theoretical from what I can see: a hypothetical risk of information leaks, and more unspecified behavior, where it's already pretty loose what happens. Where would users want to take advantage of the current invariants of NaN semantics, which they wouldn't be able to do if semantics were weakened?

[littledan]

@erights Agreed that this is a separate topic from what we discussed in Munich.

What if we think about it differently, that the NaN value doesn't actually "have" a payload (like in ES5 days), and SetValueInBuffer materializes a payload out of thin air? I'm not sure what people would use these payloads for anyway. They don't have semantics that lend them to use for data storage in any web browser currently.

[erights]

canonicalize (multiple uses)

I want to be sure we all mean the same thing by this term. The normal English and Computer Science use of "canonicalize" is to reduce all values in the same equivalence class to one agreed representative value from that class. For example, if we take all NaNs to be in one equivalence class, then canonicalizing any NaN would produce the same given canonical NaN.

As I recall from the TC39 mtg, until this was pointed out, people we using "canonicalize" in almost the opposite sense. Since @littledan started this thread with "canonicalize" in the title: @littledan , what do you mean by "canonicalize" or "canonical" here?

[erights]

@ljharb Please also clarify what you meant by "canonicalize" in your post. Thanks.

[ljharb]

@erights sorry, what i meant was: if i take two differentiable NaN values and pass them through the same code path "foo", and I get out two undifferentiable NaN values, then I consider that code path one that "canonicalizes". If I'm using the term wrong please do correct me.

[ljharb]

@erights

No one thinks "If I store this value in variable x and then read it from variable x, it might be different."

In this case, writing into an array isn't storing it in a variable, it's storing it on an object property - and if nobody expects that behavior with object properties, then why does the language have setters?

[erights]

Getters and setters are functions. "storing" and "reading" from an accessor property are function invocations. If those functions merely pass the value around opaquely, for example, if the setter merely stores it in a variable it shares with the getter, and the getter merely reads that variable and returns its value, then the same constraint applies. If the setter or getter explicitly calculates a new NaN, that's a completely different story. It would be the same as invoking any other function that explicitly calculates a new NaN.

[erights]

@ljharb @littledan We only care about what is observable. If the only way to observe the bits of a NaN value is via SetValueInBuffer, and if this always canonicalizes so that we always observe only the same bit pattern for all NaNs, then, as far as is observable, this bit pattern is the only bit pattern that implementation assigns to NaN values. Such an implementation would agree with the consensus from the last tc39 mtg.

[concavelenz]

I'm a little confused. In what way are the different NaN values observable
from JS? If you can't write code to detect different NaN values what does
it matter whether the values are canonicalized or not?

On Thu, Jul 7, 2016 at 6:02 PM, Mark S. Miller notifications@github.com
wrote:

@ljharb https://github.com/ljharb @littledan
https://github.com/littledan We only care about what is observable. If
the only way to observe the bits of a NaN value is via SetValueInBuffer,
and if this always canonicalizes so that we always observe only the same
bit pattern for all NaNs, then, as far as is observable, this bit
pattern is the only bit pattern that implementation assigns to NaN values.
Such an implementation would agree with the consensus from the last tc39
mtg.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#635 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABMDKiozv7F04IgiLHnWx9kjZ7Enq8Joks5qTaGOgaJpZM4JHj3w
.

[erights]

Serializing them to a typed array whose storage is then viewed via a different type.

[ljharb]

@concavelenz http://npmjs.com/get-nans has a few examples.

[littledan]

Sorry, by 'canonicalize' I meant in the obscure sense of replacing a NaN with any other NaN. Any suggestions for another word for this operation?

Replacing with a particular other NaN value on SetValueInBuffer would have serious negative performance implications for V8, and we previously got consensus at TC39 not to do that for this reason.

[leobalter]

Replacing with a particular other NaN value on SetValueInBuffer would have serious negative performance implications for V8, and we previously got consensus at TC39 not to do that for this reason.

I remember that and I believe that should not be the point to canonicalize NaN values. I also guess having the same NaN generated by every distinguishable operations affects performance.

The trick is to canonicalize NaNs when written into such an array, and use a particular NaN value for "the hole" to indicate that a lookup on the prototype is needed.

How would that differentiate from SetValueInBuffer for TypedArrays?

I'm wondering, is there a way that we could weaken this requirement?

By weakening that requirement you mean something like this: An implementation may choose any IEEE 754 valid encoding for each implementation distinguishable NaN value. ?

Canonicalization would still be valid as keeping the payload would be valid as well. That would be implementation defined and the standards would not enforce distinguishable encodings we could observe.

what if we simply removed that sentence and let SetValueInBuffer write whatever NaN representation it felt like? Is there another way we could convince ourselves that information leaks won't happen?

I'm +1 for that or anything that looks like that phrase I mentioned.