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

Mark S. Miller erights at google.com
Tue Mar 26 00:54:55 PDT 2013


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




>
> 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.



>
>
>> 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.



>
> 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/4e23c2ce/attachment.html>


More information about the es-discuss mailing list