shithub: opus

Info  •  Files  •  Log  •  Branches

Security Considerations update

--- a/doc/draft-ietf-codec-opus.xml

+++ b/doc/draft-ietf-codec-opus.xml

@@ -5417,7 +5417,7 @@

 <section anchor="security" title="Security Considerations">

 <t>

-The codec needs to take appropriate security considerations

+Implementations of the Opus codec need to take appropriate security considerations

 into account, as outlined in <xref target="DOS"/> and <xref target="SECGUIDE"/>.

 It is extremely important for the decoder to be robust against malicious

 payloads.

@@ -5434,16 +5434,31 @@

  in CPU load.

 However, on certain CPU architectures where denormalized floating-point

  operations are much slower than normal floating-point operations, it is

- possible for some audio content (e.g., silence or near-silence) to cause such

+ possible for some audio content (e.g., silence or near-silence) to cause a certain

  an increase in CPU load.

 Denormals can be introduced by reordering operations in the compiler and depend

  on the target architecture, so it is difficult to guarantee that an implementation

  avoids them.

-For such architectures, it is RECOMMENDED that one add very small

- floating-point offsets to prevent significant numbers of denormalized

- operations or to configure the hardware to treat denormals as zero (DAZ).

-<!--TODO: Add small offsets to what? We should be explicit-->

+For architectures on which denormals are problematic, it is RECOMMENDED to 

+add very small floating-point offsets to the affected signals

+to prevent significant numbers of denormalized

+ operations. Alternatively, it is often possible to configure the hardware to treat

+ denormals as zero (DAZ).

 No such issue exists for the fixed-point reference implementation.

+</t>

+<t>The reference implementation was validated in the following conditions:

+<list style="numbers">

+<t>Sending the decoder valid packets generated by the reference encoder and 

+verifying that the decoder's final range coder state matches that of the encoder.</t>

+<t>Sending the decoder packets generated by the reference encoder, after random corruption.</t>

+<t>Sending the decoder random packets to the decoder.</t>

+<t>Altering the encoder to make random coding decisions (internal fuzzing), including

+mode switching and verifying that the range coder final states match.</t>

+</list>

+In all of the conditions above, both the encoder and the decoder were run inside

+the Valgrind memory debugger, which tracks reads and writes to invalid memory 

+regions, as well as use of uninitialized memory. There were no error reported

+on any of the tested conditions.

 </t>

 </section>