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

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Tue Mar 26 23:53:43 PDT 2013


On Tue, Mar 26, 2013 at 10:29 AM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski <
> jussi.kalliokoski at gmail.com> wrote:
>
> 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
>
>
> That's true in any language - comparing to NaN is almost always defined
> explicitly as producing false.  You're not looking at bit patterns, here so
> conflating NaN compares with bit values is kind of pointless.
>
>
>
>
>
>
>>
>>
>>
>>>
>>>
>>>> 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. ;)
>
>
> Ok, I'll try to go over this again, because for whatever reason it doesn't
> appear to stick:
>
> If you have a double-typed array, and access a member:
> typedArray[0]
>
> Then in ES it is a double that can be one of these values: +Infinitity,
> -Infinity, NaN, or a discrete value representable in IEEE double spec.
>  There are no signaling NaNs, nor is there any exposure of what the
> underlying bit pattern of the NaN is.
>
> So the runtime loads this double, and then stores it somewhere, anywhere,
> it doesn't matter where, eg.
> var tmp = typedArray[0];
>
> Now you store it:
> typedArray[whatever] = tmp;
>
> The specification must allow a bitwise comparison of typedArray[whatever]
> to typedArray[0] to return false, as it is not possible for any NaN-boxing
> engine to maintain the bit equality that you would otherwise desire, as
> that would be trivially exploitable.  When I say security and correctness i
> mean it in the "can't be remotely pwned" sense.
>
> Given that we can't guarantee that the bit pattern will remain unchanged
> the spec should mandate normalizing to the non-signalling NaN.
>
> --Oliver
>

It's not trivially exploitable, at least not in SM or V8. I modified the
example Mark made [1] and ran it through js (SpiderMonkey) and node (V8) to
observe some of the differences of how they handle NaN. Neither could be
pwned using the specified method. In V8, the difference is observable only
if you assign the funny NaN directly to the array (i.e. it doesn't go
through a variable or stuff like that). In SM, the difference is more
observable, i.e. the bit pattern gets transferred even if you assign it to
a variable in between, but no observable enough to make pwning possible. Of
course, feel free to fork the gist and show me how it can be exploited. :)

Regardless, as per Dmitry's observations, I don't think the performance hit
can be dismissed, and I doubt it can be optimized away to a level that
could be dismissed.

I think standardizing whatever V8 is doing with NaN right now seems like
the best option.

Cheers,
Jussi

[1] https://gist.github.com/jussi-kalliokoski/5252226


>
>
>
> 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/20130327/f1e9f255/attachment-0001.html>


More information about the es-discuss mailing list