Re: Observability of NaN distinctions — is this a concern?

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Tue Mar 26 01:12:30 PDT 2013


On Tue, Mar 26, 2013 at 9:54 AM, Mark S. Miller <erights at google.com> wrote:

>
>
>
> On Tue, Mar 26, 2013 at 6:40 AM, Jussi Kalliokoski <
> jussi.kalliokoski at gmail.com> wrote:
>
>>
>> On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt <oliver at apple.com> wrote:
>>
>>>
>>> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
>>> wrote:
>>>
>>> >
>>> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
>>> >
>>> >> Right, thanks for the reminder. It all comes back now, including the
>>> "how to write correct ending-independent typed array code" bit.
>>> >
>>> > Ok, so looping back to my earlier observation.  It sounds like
>>> endian-ness can be observed by writing into an Float64Array element and
>>> then reading back from a Uint8Array that is backed by the same buffer.  If
>>> there is agreement that this doesn't represent a significant
>>> interoperability hazard can we also agree that not doing NaN
>>> cannonicalization on writes to FloatXArray is an even less significant
>>> hazard and need not be mandated?
>>> >
>>>
>>> The reason I have pushed for NaN canonicalization is because it means
>>> that it allows (and in essence requires) that typedArray[n] = typedArray[n]
>>> can modify the bit value of typedArray[n].
>>>
>>> An implementation _may_ be able to optimize the checks away in some
>>> cases, but most engines must perform checks on read unless they can prove
>>> that they were the original source of the value being read.
>>>
>>> Forcing canonicalization simply means that you are guaranteed that a
>>> certain behavior will occur, and so won't be bitten by some tests changing
>>> behavior that you may have seen during testing.  I know Ken hates these
>>> sorts of things, but seriously in the absence of a real benchmark, that
>>> shows catastrophic performance degradation due to this, simply saying "this
>>> is extra work that will burn cpu cycles" without evidence is a waste of
>>> time.
>>
>>
>> I also disagree with you.
>>
>>
>>> Also there is absolutely no case in which abstract performance concerns
>>> should ever outweigh absolute security and correctness bugs.
>>>
>>
>> Could you elaborate on the security part? I doubt NaN distinctions can
>> really be of any significant use for fingerprinting, etc.
>>
>
>
> In SES, Alice says:
>
>     var bob = confinedEval(bobSrc);
>
>     var carol = confinedEval(carolSrc);
>
>     // At this point, bob and carol should be unable to communicate with
>     // each other, and are in fact completely isolated from each other
>     // except that Alice holds a reference to both.
>     // See <http://www.youtube.com/watch?v=w9hHHvhZ_HY> start
>     // at about 44 minutes in.
>
>     var shouldBeImmutable = Object.freeze(Object.create(null, {foo:
> {value: NaN}}));
>
>     bob(shouldBeImmutable);
>
>     carol(shouldBeImmutable);
>
>     // Alice, by sharing this object with bob and carol, should still be
> able
>     // to assume that they are isolated from each other
>
> Bob says:
>
>     var FunnyNaN = // expression creating NaN with non-canonical internal
> rep
>     // on this platform, perhaps created by doing funny typed array tricks
>
>     if (wantToCommunicate1bitToCarol) {
>       Object.defineProperty(shouldBeImmutable, 'foo', {value: FunnyNaN});
>
>     // The [[DefineProperty]] algorithm is allowed to overwrite
> shouldBeImmutable.foo
>     // with FunnyNaN, since it passes the SameValue check.
>
> Carol says:
>
>     if (isNaNFunny(shouldBeImmutable.foo)) {
>     // where isNaNFunny uses typed array tricks to detect whether its
> argument has
>     // a non-canonical rep on this this platform
>
>
The NaN distinction is only observable in the byte array, not if you
extract the value, because at that point it becomes an ES NaN value, so
that example is invalid.


>
>
>>
>> So far I've yet to come across any unexpected bugs caused by this, maybe
>> you have examples? NaN is usually a non-desired value so if you write a NaN
>> you probably had a bug in the first place.
>>
>> And about correctness, by definition NaN is a category, not a value; by
>> definition a NaN value is not the same as another NaN value. If you want to
>> canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;)
>>
>
> You're confusing IEEE NaN with ES NaN. In ES, NaN is a value, not a bit
> pattern. In IEEE, NaN is a family of bit patterns. Type arrays make us face
> the issue of what IEEE NaN bit pattern an ES NaN value converts to.
>

That's just because ES has had no notion of bits for floating points
before. Other than that, ES NaN works like IEEE NaN, e.g.

0/0 === NaN // false
isNaN(0/0) // true



>
>
>
>>
>>
>>> We need to stop raising "this causes performance problems" type issues
>>> without a concrete example of that problem.  I remember having to work very
>>> hard to stop WebGL from being a gaping security hole in the first place and
>>> it's disappointing to see these same issues being re-raised in a different
>>> forum to try and get them bypassed here.
>>>
>>
>> Before saying security hole, please elaborate. Also, when it comes to
>> standards, I think change should be justified with data, rather than the
>> other way around.
>>
>
> Done.
>

You'll have to do better than that. ;)

Cheers,
Jussi


>
>
>
>>
>> Cheers,
>> Jussi
>>
>>
>>> --Oliver
>>>
>>> > Allen
>>> >
>>> >
>>> >
>>> >
>>> >>
>>> >> /be
>>> >>
>>> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <kbr at google.com> wrote:
>>> >>
>>> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <brendan at mozilla.com>
>>> wrote:
>>> >>>> Allen Wirfs-Brock wrote:
>>> >>>>>
>>> >>>>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
>>> >>>>>
>>> >>>>>> Allen Wirfs-Brock wrote:
>>> >>>>>>>
>>> >>>>>>> BTW, isn't cannonicalization of endian-ness for both integers
>>> and floats
>>> >>>>>>> a bigger interop issue than NaN cannonicalization?  I know this
>>> was
>>> >>>>>>> discussed in the past, but it doesn't seem to be covered in the
>>> latest
>>> >>>>>>> Khronos spec.  Was there ever a resolution as to whether or not
>>> TypedArray
>>> >>>>>>> [[Set]] operations need to use a cannonical endian-ness?
>>> >>>>>>
>>> >>>>>> Search for "byte order" at
>>> >>>>>> https://www.khronos.org/registry/typedarray/specs/latest/.
>>> >>>>>
>>> >>>>>
>>> >>>>> I had already search for "endian" with similar results.  It says
>>> that the
>>> >>>>> default for DataViews gets/sets that do not specify a byte order is
>>> >>>>> big-endean. It doesn't say anything (that I can find) about such
>>> accesses on
>>> >>>>> TypedArray gets/sets.
>>> >>>>
>>> >>>>
>>> >>>> Oh, odd -- I recall that it used to say little-endian. Typed arrays
>>> are LE
>>> >>>> to match dominant architectures, while DataViews are BE to match
>>> packed
>>> >>>> serialization use-cases.
>>> >>>>
>>> >>>> Ken, did something get edited out?
>>> >>>
>>> >>> No. The typed array views (everything except DataView) have used the
>>> >>> host machine's endianness from day one by design -- although the
>>> typed
>>> >>> array spec does not state this explicitly. If desired, text can be
>>> >>> added to the specification to this effect. Any change in this
>>> behavior
>>> >>> will destroy the performance of APIs like WebGL and Web Audio on
>>> >>> big-endian architectures.
>>> >>>
>>> >>> Correctly written code works identically on big-endian and
>>> >>> little-endian architectures. See
>>> >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a
>>> >>> detailed description of the usage of the APIs.
>>> >>>
>>> >>> DataView, which is designed for input/output, operates on data with a
>>> >>> specified endianness.
>>> >>>
>>> >>> -Ken
>>> >>> _______________________________________________
>>> >>> es-discuss mailing list
>>> >>> es-discuss at mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>> >> _______________________________________________
>>> >> es-discuss mailing list
>>> >> es-discuss at mozilla.org
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130326/e647f38e/attachment-0001.html>


More information about the es-discuss mailing list