Re: Proposal for fixing race conditions

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




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


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

Chris