Safe C Library - README
=======================
:toc:


Copying
-------
This project's licensing restrictions are documented in the file 'COPYING'
under the root directory of this release.

Overview
--------
The ISO TR24731 Bounds Checking Interface documents indicate that the key
motivation for the new specification is to help mitigate the ever increasing
security attacks, specifically the buffer overrun.

The rationale document says ``Buffer overrun attacks continue to be a security
problem. Roughly 10% of vulnerability reports cataloged by CERT from
01/01/2005 to 07/01/2005 involved buffer overflows. Preventing buffer overruns
is the primary, but not the only, motivation for this technical report.''

The rationale document continues ``that these only mitigate, that is lessen,
security problems. When used properly, these functions decrease the danger
buffer overrun attacks. Source code may remain vulnerable due to other bugs
and security issues. The highest level of security is achieved by building in
layers of security utilizing multiple strategies.''

.The rationale document lists the following key points for TR24731:
- Guard against overflowing a buffer
- Do not produce unterminated strings
- Do not unexpectedly truncate strings
- Provide a library useful to existing code
- Preserve the null terminated string datatype
- Only require local edits to programs
- Library based solution
- Support compile-time checking
- Make failures obvious
- Zero buffers, null strings
- Runtime-constraint handler mechanism
- Support re-entrant code
- Consistent naming scheme
- Have a uniform pattern for the function parameters and return type
- Deference to existing technology

and the following can be added...

- provide a library of functions with like behavior
- provide a library of functions that promote and increase code safety and
  security
- provide a library of functions that are efficient


Design Considerations
---------------------
This library only implements a subset of the functions defined in the
specification.  Included in the library are extensions to the specification to
provide a complementary set of functions with like behavior.


=== Use of errno

The TR24731 specification says an implementation may set errno for the
functions defined in the technical report, but is not required to.  This
library does not set errno.  The library does use errno return codes as
required by functional APIs.  Specific Safe C String and Safe C Memory errno
codes are defined in the safe_errno.h file.


=== Runtime-constraints

Per the spec, the library verifies that the calling program does not violate
the function's runtime-constraints. If a runtime-constraint is violated, the
library calls the currently registered runtime-constraint handler.

Per the spec, multiple runtime-constraint violations in the same call to a
library function result in only one call to the runtime-constraint handler.
The first violation encountered invokes the runtime-constraint handler.

The runtime-constraint handler might not return. If the handler does return,
the library function whose runtime-constraint was violated returns an
indication of failure as given by the function’s return.

rsize_t::
	The specification defines a new type.  This type, rsize_t, is
	conditionally defined in the safe_lib.h header file.

RSIZE_MAX::
	The specification defines the macro RSIZE_MAX which expands to a value
	of type rsize_t. The specification uses RSIZE_MAX for both the string
	functions and the memory functions. This implementation defines two
	macros: RSIZE_MAX_STR and RSIZE_MAX_MEM.  RSIZE_MAX_STR defines the
	range limit for the safe string functions.  RSIZE_MAX_MEM defines the
	range limit for the safe memory functions.  The point is that string
	limits can and should be different from memory limits.


=== Header Files

The specification states the various functions would be added to existing
Standard C header files: stdio.h, string.h, etc.  This implementation
separates the memory related functions into the safe_mem_lib.h header and the
string related functions into the safe_str_lib.h header.  The make file builds
a single library safe_lib.a in the ../lib directory.

It is possible to split the make such that a separate safe_mem_lib.a and
safe_str_lib.a are built.  It is also possible to integrate the prototypes
into the Standard C header files, but that may require changes to your
development tool chain.


Userspace Library
-----------------
The build system for the userspace library is the well known *GNU build
system*, a.k.a. Autotools. This system is well understood and supported
by many different platforms and distributions which should allow this
library to be built on a wide variety of platforms. See the
xref:tested-platforms[``Tested Platforms''] section for details on what
platforms this library was tested on during its development.


=== Building

For those familiar with autotools you can probably skip this part. For those
not and want to get right to building the code see below. And, for those that
need additional information see the 'INSTALL' file in the same directory.

.To build you do the following:
----
prompt$ ./build-tools/autogen.sh
prompt$ ./configure
prompt$ make
----
'autogen.sh' only needs to be run if you are building from the git
repository. Optionally, you can do ``make check'' if you want to run the unit
tests.


=== Installing

Installation must be preformed by an `Adminstrator' on most systems. The
following is used to install the library.

----
prompt$ sudo make install
----


Safe Linux Kernel Module
------------------------
The build for the kernel module has not been integrated into the autotools
build infrastructure. Consequently, you have to run a different makefile to
build the kernel module.


=== Building

.To build do the following:
----
prompt$ ./configure
prompt$ make -f Makefile.kernel
----

This assumes you are compiling on a Linux box and this makefile supports the
standard kernel build system infrastructure documented in:
<linux-kernel-src-tree>/Documentation/kbuild/modules.txt

NOTE: If you build the kernel module then wish to build the userspace library
      or vice versa you will need to do a +make clean+ otherwise a +make check+
      will fail to build.


=== Installing

The kernel module will be found at the root of the source tree called
'slkm.ko'. The file 'testslkm.ko' are the unit tests run on the userspace
library but in Linux kernel module form to verify functionality within the
kernel.


[[tested-platforms]]
Tested Platforms
----------------
.The library has been tested on the following systems
- Mac OSX 10.6.8 w/ Apple developer tools installed
- Linux Ubuntu 10.04 kernel version v2.6.32-42-generic
- User Mode Linux (UML), Linux kernel version v3.5.3 w/ Debian Squeeze rootfs


Known Issues
------------
1. If you are building the library from the git repository you will have to
   first run build-tools/autogen.sh which runs autoreconf to ``install'' the
   autotools files and create the configure script. On Mac OSX you may see a
   warning about ``AC_FOREACH is obsolete'' this can be ignored as the library
   will still build correctly.


[bibliography]
.References
- [[[1]]] Programming languages, their environments and system software
          interfaces, Extensions to the C Library, Part I: Bounds-checking
          interfaces, ISO/IEC TR 24731-1.
- [[[2]]] Rationale for TR 24731 Extensions to the C Library Part I:
          Bounds-checking interfaces, ISO/IEC JTC1 SC22 WG14 N1225.
- [[[3]]] The Open Group Base Specifications Issue 7
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html
- [[[4]]] CERT C Secure Coding Standard
          https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard