186 lines
7.1 KiB
XML
186 lines
7.1 KiB
XML
<?xml version='1.0' encoding='utf-8' ?>
|
|
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
]>
|
|
<section id="sect-Defensive_Coding-CXX-Language">
|
|
<title>The core language</title>
|
|
<para>
|
|
C++ includes a large subset of the C language. As far as the C
|
|
subset is used, the recommendations in <xref
|
|
linkend="chap-Defensive_Coding-C"/> apply.
|
|
</para>
|
|
|
|
<section>
|
|
<title>Array allocation with <literal>operator new[]</literal></title>
|
|
<para>
|
|
For very large values of <literal>n</literal>, an expression
|
|
like <literal>new T[n]</literal> can return a pointer to a heap
|
|
region which is too small. In other words, not all array
|
|
elements are actually backed with heap memory reserved to the
|
|
array. Current GCC versions generate code that performs a
|
|
computation of the form <literal>sizeof(T) * size_t(n) +
|
|
cookie_size</literal>, where <literal>cookie_size</literal> is
|
|
currently at most 8. This computation can overflow, and
|
|
GCC-generated code does not detect this.
|
|
</para>
|
|
<para>
|
|
The <literal>std::vector</literal> template can be used instead
|
|
an explicit array allocation. (The GCC implementation detects
|
|
overflow internally.)
|
|
</para>
|
|
<para>
|
|
If there is no alternative to <literal>operator new[]</literal>,
|
|
code which allocates arrays with a variable length must check
|
|
for overflow manually. For the <literal>new T[n]</literal>
|
|
example, the size check could be <literal>n || (n > 0 &&
|
|
n > (size_t(-1) - 8) / sizeof(T))</literal>. (See <xref
|
|
linkend="sect-Defensive_Coding-C-Arithmetic"/>.) If there are
|
|
additional dimensions (which must be constants according to the
|
|
C++ standard), these should be included as factors in the
|
|
divisor.
|
|
</para>
|
|
<para>
|
|
These countermeasures prevent out-of-bounds writes and potential
|
|
code execution. Very large memory allocations can still lead to
|
|
a denial of service. <xref
|
|
linkend="sect-Defensive_Coding-Tasks-Serialization-Decoders"/>
|
|
contains suggestions for mitigating this problem when processing
|
|
untrusted data.
|
|
</para>
|
|
<para>
|
|
See <xref linkend="sect-Defensive_Coding-C-Allocators-Arrays"/>
|
|
for array allocation advice for C-style memory allocation.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Overloading</title>
|
|
<para>
|
|
Do not overload functions with versions that have different
|
|
security characteristics. For instance, do not implement a
|
|
function <function>strcat</function> which works on
|
|
<type>std::string</type> arguments. Similarly, do not name
|
|
methods after such functions.
|
|
</para>
|
|
</section>
|
|
<section>
|
|
<title>ABI compatibility and preparing for security updates</title>
|
|
<para>
|
|
A stable binary interface (ABI) is vastly preferred for security
|
|
updates. Without a stable ABI, all reverse dependencies need
|
|
recompiling, which can be a lot of work and could even be
|
|
impossible in some cases. Ideally, a security update only
|
|
updates a single dynamic shared object, and is picked up
|
|
automatically after restarting affected processes.
|
|
</para>
|
|
<para>
|
|
Outside of extremely performance-critical code, you should
|
|
ensure that a wide range of changes is possible without breaking
|
|
ABI. Some very basic guidelines are:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Avoid inline functions.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Use the pointer-to-implementation idiom.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Try to avoid templates. Use them if the increased type
|
|
safety provides a benefit to the programmer.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Move security-critical code out of templated code, so that
|
|
it can be patched in a central place if necessary.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
The KDE project publishes a document with more extensive
|
|
guidelines on ABI-preserving changes to C++ code, <ulink
|
|
url="http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++">Policies/Binary
|
|
Compatibility Issues With C++</ulink>
|
|
(<emphasis>d-pointer</emphasis> refers to the
|
|
pointer-to-implementation idiom).
|
|
</para>
|
|
</section>
|
|
|
|
<section id="sect-Defensive_Coding-CXX-Language-CXX11">
|
|
<title>C++0X and C++11 support</title>
|
|
<para>
|
|
GCC offers different language compatibility modes:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<option>-std=c++98</option> for the original 1998 C++
|
|
standard
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<option>-std=c++03</option> for the 1998 standard with the
|
|
changes from the TR1 technical report
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<option>-std=c++11</option> for the 2011 C++ standard. This
|
|
option should not be used.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<option>-std=c++0x</option> for several different versions
|
|
of C++11 support in development, depending on the GCC
|
|
version. This option should not be used.
|
|
<!-- There were two incompatibilies before GCC 4.7.2
|
|
(std::list and std::pair), but link C++98 and C++11
|
|
code is still unsupported, although it currently has
|
|
some chance of working by accident. -->
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
For each of these flags, there are variants which also enable
|
|
GNU extensions (mostly language features also found in C99 or
|
|
C11): <option>-std=gnu++98</option>,
|
|
<option>-std=gnu++03</option>, <option>-std=gnu++11</option>.
|
|
Again, <option>-std=gnu++11</option> should not be used.
|
|
</para>
|
|
<para>
|
|
If you enable C++11 support, the ABI of the standard C++ library
|
|
<literal>libstdc++</literal> will change in subtle ways.
|
|
Currently, no C++ libraries are compiled in C++11 mode, so if
|
|
you compile your code in C++11 mode, it will be incompatible
|
|
with the rest of the system. Unfortunately, this is also the
|
|
case if you do not use any C++11 features. Currently, there is
|
|
no safe way to enable C++11 mode (except for freestanding
|
|
applications).
|
|
</para>
|
|
<para>
|
|
The meaning of C++0X mode changed from GCC release to GCC
|
|
release. Earlier versions were still ABI-compatible with C++98
|
|
mode, but in the most recent versions, switching to C++0X mode
|
|
activates C++11 support, with its compatibility problems.
|
|
</para>
|
|
<para>
|
|
Some C++11 features (or approximations thereof) are available
|
|
with TR1 support, that is, with <option>-std=c++03</option> or
|
|
<option>-std=gnu++03</option> and in the
|
|
<literal><tr1/*></literal> header files. This includes
|
|
<literal>std::tr1::shared_ptr</literal> (from
|
|
<literal><tr1/memory></literal>) and
|
|
<literal>std::tr1::function</literal> (from
|
|
<literal><tr1/functional></literal>). For other C++11
|
|
features, the Boost C++ library contains replacements.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|