Re: Proposal for fixing race conditions

On Thu, Jul 18, 2013 at 1:58 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Thu, Jul 18, 2013 at 4:23 AM, Srikumar Karaikudi Subramanian <
> srikumarks@gmail.com> wrote:
>
>>  You're simplifying my position a bit.
>>
>>
>> Perhaps ...
>>
>> What I'm saying is there are no sensible or normal calling patterns where
>> this type of race conditions is even a possibility.  As the API is designed
>> and has been used for over 2 years, these calling patterns are not used and
>> so simply are not an issue.  We do have substantial developer experience to
>> support this view, and these developers come from a wide range of
>> backgrounds and experience levels from complete novices playing with audio
>> for the first time, all the way to seasoned professional audio developers.
>>
>>
>> .. but the ignorability of nonsensical and abnormal calling patterns
>> depends on the impact that any race condition possibility in the API can
>> have. If, for example, they can be used to compromise the security of the
>> browser sandbox, say, because these buffers are hooking into high priority
>> scheduling at the OS level, then wouldn't it be worth making even
>> compatibility breaking changes or taking some constant malloc+memcpy hits
>> to solve that? So it does seem to me that the fact that such calling
>> patterns cannot cause harm beyond garbled audio output is the key behind
>> this argument.
>>
>
> But Srikumar, we're currently talking about a situation which is not a
> security issue as you describe.  Unless you have very specific and concrete
> issues in that regard, please don't make such vague statements implying
> that kind of risk.
>

Yes, there are no security issues to worry about here.

That's why I was saying that in the case where somebody does actually write
> some nonsensical code that there is little risk, other than the sound
> playing wrong.
>

Well, other than the sound playing correctly on one browser/machine and
wrong in another (perhaps the users machine if the developer is unlucky!).


> In all of the APIs which exist today there are so many ways to write buggy
> JS/HTML/CSS code which will draw random pixels on the screen, send
> incorrect bytes to a server, layout divs badly on a page because of
> incorrect CSS, make incorrect assumptions about the order of event
> handlers, setTimeout, etc. getting called.  What we can do is teach best
> practices about using all of these APIs and spread that knowledge.
>

No, sorry, this has nothing to do with writing buggy code.  Code which hits
these race conditions will be completely fine with respect to what the spec
suggests, and chances are that it might even work fine on the
configurations that the developer tests them in, but it will be broken in
others.  This is also not about problems caused by relying on the order of
asynchronous operations, this is about two threads racing when accessing
the same data.  Those are completely different problems.  The Web platform
does not attempt to protect against the first type of problem, but it does
protect against the second class of problems.  The current Web Audio spec
is the *only* part of the Web platform where data races are allowed.


>
>
>>
>> The benign-ness of the current race conditions seems (to me) likely,
>> since the lengths of ArrayBuffers cannot be changed. If their lengths can
>> be changed, the current API might permit buffer overrun exploits (still
>> only guessing here). Even if they can't be changed, there could exist small
>> windows of vulnerability in an implementation where the length of an array
>> is kept around while an updated pointer to the array data is taken.
>>
>
> You can always speculate about what types of mistakes and bugs could exist
> in a specific browser implementation.  But if you do find any issues which
> you do believe to be security related, please contact the individual
> browser vendors privately.  There is certainly nothing in the design which
> prevents a safe implementation.
>

Let's stay on the concrete problem of the data race conditions which we
know are a problem today then.  I believe that the only disagreement that
we have so far is that you don't think we should fix this problem, but I
thought we all agreed that it _is_ a problem.


>
>
>>
>> So, we ought to first take race conditions seriously and at least prove
>> that they cannot cause serious harm before deciding they are not a problem
>> in a design.
>>
>
> We have looked at it in quite some detail, and so far we believe we have a
> safe solution.
>


What is that safe solution?


--
Ehsan
<http://ehsanakhgari.org/>