GFSDK_HBAO+_distro_r3.0_cl20573789

1 files changed, 221 insertions, 0 deletions

diff --git a/build/tools/HLSLcc/May_2014/src/cbstring/security.txt b/build/tools/HLSLcc/May_2014/src/cbstring/security.txt
new file mode 100644
index 0000000..9761409
--- /dev/null
+++ b/build/tools/HLSLcc/May_2014/src/cbstring/security.txt
@@ -0,0 +1,221 @@
+Better String library Security Statement
+----------------------------------------
+
+by Paul Hsieh
+
+===============================================================================
+
+Introduction
+------------
+
+The Better String library (hereafter referred to as Bstrlib) is an attempt to 
+provide improved string processing functionality to the C and C++ languages.  
+At the heart of the Bstrlib is the management of "bstring"s which are a 
+significant improvement over '\0' terminated char buffers.  See the 
+accompanying documenation file bstrlib.txt for more information.
+
+DISCLAIMER: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
+CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 
+NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; 
+OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
+OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Like any software, there is always a possibility of failure due to a flawed
+implementation.  Nevertheless a good faith effort has been made to minimize 
+such flaws in Bstrlib.  Also, use of Bstrlib by itself will not make an 
+application secure or free from implementation failures.  However, it is the
+author's conviction that use of Bstrlib can greatly facilitate the creation 
+of software meeting the highest possible standards of security.
+
+Part of the reason why this document has been created, is for the purpose of 
+security auditing, or the creation of further "Statements on Security" for 
+software that is created that uses Bstrlib.  An auditor may check the claims 
+below against Bstrlib, and use this as a basis for analysis of software which 
+uses Bstrlib.
+
+===============================================================================
+
+Statement on Security
+---------------------
+
+This is a document intended to give consumers of the Better String Library
+who are interested in security an idea of where the Better String Library 
+stands on various security issues.  Any deviation observed in the actual 
+library itself from the descriptions below should be considered an 
+implementation error, not a design flaw.
+
+This statement is not an analytical proof of correctness or an outline of one
+but rather an assertion similar to a scientific claim or hypothesis.  By use,
+testing and open independent examination (otherwise known as scientific 
+falsifiability), the credibility of the claims made below can rise to the 
+level of an established theory.
+
+Common security issues:
+.......................
+
+1. Buffer Overflows
+
+The Bstrlib API allows the programmer a way to deal with strings without 
+having to deal with the buffers containing them.  Ordinary usage of the 
+Bstrlib API itself makes buffer overflows impossible.
+
+Furthermore, the Bstrlib API has a superset of basic string functionality as 
+compared to the C library's char * functions, C++'s std::string class and 
+Microsoft's MFC based CString class.  It also has abstracted mechanisms for 
+dealing with IO.  This is important as it gives developers a way of migrating 
+all their code from a functionality point of view.
+
+2. Memory size overflow/wrap around attack
+
+Bstrlib is, by design, impervious to memory size overflow attacks.  The 
+reason is it is resiliant to length overflows is that bstring lengths are 
+bounded above by INT_MAX, instead of ~(size_t)0.  So length addition 
+overflows cause a wrap around of the integer value making them negative 
+causing balloc() to fail before an erroneous operation can occurr.  Attempted 
+conversions of char * strings which may have lengths greater than INT_MAX are 
+detected and the conversion is aborted.
+
+It is unknown if this property holds on machines that don't represent 
+integers as 2s complement.  It is recommended that Bstrlib be carefully 
+auditted by anyone using a system which is not 2s complement based.
+
+3. Constant string protection
+
+Bstrlib implements runtime enforced constant and read-only string semantics.
+I.e., bstrings which are declared as constant via the bsStatic() macro cannot
+be modified or deallocated directly through the Bstrlib API, and this cannot
+be subverted by casting or other type coercion.  This is independent of the
+use of the const_bstring data type.
+
+The Bstrlib C API uses the type const_bstring to specify bstring parameters 
+whose contents do not change.  Although the C language cannot enforce this,
+this is nevertheless guaranteed by the implementation of the Bstrlib library
+of C functions.  The C++ API enforces the const attribute on CBString types
+correctly.
+
+4. Aliased bstring support
+
+Bstrlib detects and supports aliased parameter management throughout the API. 
+The kind of aliasing that is allowed is the one where pointers of the same
+basic type may be pointing to overlapping objects (this is the assumption the 
+ANSI C99 specification makes.)  Each function behaves as if all read-only 
+parameters were copied to temporaries which are used in their stead before 
+the function is enacted (it rarely actually does this).  No function in the 
+Bstrlib uses the "restrict" parameter attribute from the ANSI C99 
+specification.
+
+5. Information leaking
+
+In bstraux.h, using the semantically equivalent macros bSecureDestroy() and 
+bSecureWriteProtect() in place of bdestroy() and bwriteprotect() respectively 
+will ensure that stale data does not linger in the heap's free space after 
+strings have been released back to memory.  Created bstrings or CBStrings
+are not linked to anything external to themselves, and thus cannot expose 
+deterministic data leaking.  If a bstring is resized, the preimage may exist
+as a copy that is released to the heap.  Thus for sensitive data, the bstring 
+should be sufficiently presized before manipulated so that it is not resized. 
+bSecureInput() has been supplied in bstraux.c, which can be used to obtain 
+input securely without any risk of leaving any part of the input image in the 
+heap except for the allocated bstring that is returned.
+
+6. Memory leaking
+
+Bstrlib can be built using memdbg.h enabled via the BSTRLIB_MEMORY_DEBUG 
+macro.  User generated definitions for malloc, realloc and free can then be
+supplied which can implement special strategies for memory corruption 
+detection or memory leaking.  Otherwise, bstrlib does not do anything out of 
+the ordinary to attempt to deal with the standard problem of memory leaking 
+(i.e., losing references to allocated memory) when programming in the C and 
+C++ languages.  However, it does not compound the problem any more than exists 
+either, as it doesn't have any intrinsic inescapable leaks in it.  Bstrlib 
+does not preclude the use of automatic garbage collection mechanisms such as 
+the Boehm garbage collector.
+
+7. Encryption
+
+Bstrlib does not present any built-in encryption mechanism.  However, it 
+supports full binary contents in its data buffers, so any standard block 
+based encryption mechanism can make direct use of bstrings/CBStrings for 
+buffer management.
+
+8. Double freeing
+
+Freeing a pointer that is already free is an extremely rare, but nevertheless 
+a potentially ruthlessly corrupting operation (its possible to cause Win 98 to
+reboot, by calling free mulitiple times on already freed data using the WATCOM
+CRT.)  Bstrlib invalidates the bstring header data before freeing, so that in
+many cases a double free will be detected and an error will be reported 
+(though this behaviour is not guaranteed and should not be relied on).
+
+Using bstrFree pervasively (instead of bdestroy) can lead to somewhat 
+improved invalid free avoidance (it is completely safe whenever bstring
+instances are only stored in unique variables).  For example:
+
+    struct tagbstring hw = bsStatic ("Hello, world");
+    bstring cpHw = bstrcpy (&hw);
+
+    #ifdef NOT_QUITE_AS_SAFE
+        bdestroy (cpHw); /* Never fail */
+        bdestroy (cpHw); /* Error sometimes detected at runtime */
+        bdestroy (&hw);  /* Error detected at run time */
+    #else
+        bstrFree (cpHw); /* Never fail */
+        bstrFree (cpHw); /* Will do nothing */
+        bstrFree (&hw);  /* Will lead to a compile time error */
+    #endif
+
+9. Resource based denial of service
+
+bSecureInput() has been supplied in bstraux.c.  It has an optional upper limit
+for input length.  But unlike fgets(), it is also easily determined if the 
+buffer has been truncated early.  In this way, a program can set an upper limit
+on input sizes while still allowing for implementing context specific 
+truncation semantics (i.e., does the program consume but dump the extra 
+input, or does it consume it in later inputs?)
+
+10. Mixing char *'s and bstrings
+
+The bstring and char * representations are not identical.  So there is a risk
+when converting back and forth that data may lost.  Essentially bstrings can
+contain '\0' as a valid non-terminating character, while char * strings 
+cannot and in fact must use the character as a terminator.  The risk of data 
+loss is very low, since:
+
+  A) the simple method of only using bstrings in a char * semantically 
+     compatible way is both easy to achieve and pervasively supported.
+  B) obtaining '\0' content in a string is either deliberate or indicative
+     of another, likely more serious problem in the code.
+  C) the library comes with various functions which deal with this issue
+     (namely: bfromcstr(), bstr2cstr (), and bSetCstrChar ())
+
+Marginal security issues:
+.........................
+
+11. 8-bit versus 9-bit portability
+
+Bstrlib uses CHAR_BIT and other limits.h constants to the maximum extent 
+possible to avoid portability problems.  However, Bstrlib has not been tested 
+on any system that does not represent char as 8-bits.  So whether or not it 
+works on 9-bit systems is an open question.  It is recommended that Bstrlib be 
+carefully auditted by anyone using a system in which CHAR_BIT is not 8.
+
+12. EBCDIC/ASCII/UTF-8 data representation attacks.
+
+Bstrlib uses ctype.h functions to ensure that it remains portable to non-
+ASCII systems.  It also checks range to make sure it is well defined even for
+data that ANSI does not define for the ctype functions.
+
+Obscure issues:
+...............
+
+13. Data attributes
+
+There is no support for a Perl-like "taint" attribute, however, an example of 
+how to do this using C++'s type system is given as an example.
+