DataFlowSanitizer design discussion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

DataFlowSanitizer design discussion

Peter Collingbourne-2
Hi,

I am starting a thread to discuss the design of DataFlowSanitizer,
a compiler instrumentation based analysis tool which I am hoping to
bring into LLVM.  As a starting point, I have included the current
version of the design document below.  Comments are appreciated.

Thanks,
Peter

DataFlowSanitizer Design Document
*********************************

This document sets out the design for DataFlowSanitizer, a general
dynamic data flow analysis.  Unlike other Sanitizer tools, this tool
is not designed to detect a specific class of bugs on its own.
Instead, it provides a generic dynamic data flow analysis framework to
be used by clients to help detect application-specific issues within
their own code.

DataFlowSanitizer is a program instrumentation which can associate a
number of taint labels with any data stored in any memory region
accessible by the program. The analysis is dynamic, which means that
it operates on a running program, and tracks how the labels propagate
through that program. The tool shall support a large (>100) number of
labels, such that programs which operate on large numbers of data
items may be analysed with each data item being tracked separately.


Interface
=========

A number of functions are provided which will create taint labels,
attach labels to memory regions and extract the set of labels
associated with a specific memory region. These functions are declared
in the header file "sanitizer/dfsan_interface.h".

   /// Creates and returns a base label with the given description and user data.
   dfsan_label dfsan_create_label(const char *desc, void *userdata);

   /// Sets the label for each address in [addr,addr+size) to \c label.
   void dfsan_set_label(dfsan_label label, void *addr, size_t size);

   /// Sets the label for each address in [addr,addr+size) to the union of the
   /// current label for that address and \c label.
   void dfsan_add_label(dfsan_label label, void *addr, size_t size);

   /// Retrieves the label associated with the given data.
   ///
   /// The type of 'data' is arbitrary.  The function accepts a value of any type,
   /// which can be truncated or extended (implicitly or explicitly) as necessary.
   /// The truncation/extension operations will preserve the label of the original
   /// value.
   dfsan_label dfsan_get_label(long data);

   /// Retrieves a pointer to the dfsan_label_info struct for the given label.
   const struct dfsan_label_info *dfsan_get_label_info(dfsan_label label);

   /// Returns whether the given label label contains the label elem.
   int dfsan_has_label(dfsan_label label, dfsan_label elem);

   /// If the given label label contains a label with the description desc, returns
   /// that label, else returns 0.
   dfsan_label dfsan_has_label_with_desc(dfsan_label label, const char *desc);


Taint label representation
==========================

As stated above, the tool must track a large number of taint labels.
This poses an implementation challenge, as most multiple-label
tainting systems assign one label per bit to shadow storage, and union
taint labels using a bitwise or operation. This will not scale to
clients which use hundreds or thousands of taint labels, as the label
union operation becomes O(n) in the number of supported labels, and
data associated with it will quickly dominate the live variable set,
causing register spills and hampering performance.

Instead, a low overhead approach is proposed which is best-case
O(log_2 n) during execution. The underlying assumption is that the
required space of label unions is sparse, which is a reasonable
assumption to make given that we are optimizing for the case where
applications mostly copy data from one place to another, without often
invoking the need for an actual union operation. The representation of
a taint label is a 16-bit integer, and new labels are allocated
sequentially from a pool. The label identifier 0 is special, and means
that the data item is unlabelled.

When a label union operation is requested at a join point (any
arithmetic or logical operation with two or more operands, such as
addition), the code checks whether a union is required, whether the
same union has been requested before, and whether one union label
subsumes the other. If so, it returns the previously allocated union
label. If not, it allocates a new union label from the same pool used
for new labels.

Specifically, the instrumentation pass will insert code like this to
decide the union label "lu" for a pair of labels "l1" and "l2":

   if (l1 == l2)
     lu = l1;
   else
     lu = __dfsan_union(l1, l2);

The equality comparison is outlined, to provide an early exit in the
common cases where the program is processing unlabelled data, or where
the two data items have the same label.  "__dfsan_union" is a runtime
library function which performs all other union computation.

Further optimizations are possible, for example if "l1" is known at
compile time to be zero (e.g. it is derived from a constant), "l2" can
be used for "lu", and vice versa.


Memory layout and label management
==================================

The following is the current memory layout for Linux/x86_64:

+-----------------+-----------------+----------------------+
| Start           | End             | Use                  |
+=================+=================+======================+
| 0x700000008000  | 0x800000000000  | application memory   |
+-----------------+-----------------+----------------------+
| 0x200200000000  | 0x700000008000  | unused               |
+-----------------+-----------------+----------------------+
| 0x200000000000  | 0x200200000000  | union table          |
+-----------------+-----------------+----------------------+
| 0x000000010000  | 0x200000000000  | shadow memory        |
+-----------------+-----------------+----------------------+
| 0x000000000000  | 0x000000010000  | reserved by kernel   |
+-----------------+-----------------+----------------------+

Each byte of application memory corresponds to two bytes of shadow
memory, which are used to store its taint label. As for LLVM SSA
registers, we have not found it necessary to associate a label with
each byte or bit of data, as some other tools do. Instead, labels are
associated directly with registers.  Loads will result in a union of
all shadow labels corresponding to bytes loaded (which most of the
time will be short circuited by the initial comparison) and stores
will result in a copy of the label to the shadow of all bytes stored
to.

--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Sean Silva
Could you maybe give some example use cases?

Also, "sanitizer" may not be the best name for this, since it doesn't really sanitize anything.

-- Sean Silva

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Reid Kleckner-2
While dfsan as proposed isn't an error checking tool, the goal is to build domain specific error checking tools with it, which is pretty sanitizer-like.

The big question is basically how much utility the LLVM community thinks there is in having a taint analysis framework available upstream.  I imagine there are *many* researchers in program analysis out there who would love to have some standard, easy-to-use taint framework for native code.  This is the kind of thing that's trivial to implement for Java but so far intractable for native code.


On Thu, Jun 13, 2013 at 6:13 PM, Sean Silva <[hidden email]> wrote:
Could you maybe give some example use cases?

Also, "sanitizer" may not be the best name for this, since it doesn't really sanitize anything.

-- Sean Silva

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Peter Collingbourne-2
In reply to this post by Sean Silva
On Thu, Jun 13, 2013 at 03:13:37PM -0700, Sean Silva wrote:
> Could you maybe give some example use cases?

A use case I am interested in is to take a large application and use
this instrumentation as a tool to help monitor how data flows from its
inputs (sources) to its outputs (sinks).  This has applications from
a privacy/security perspective in that one can audit how a sensitive
data item is used within a program and ensure it isn't exiting the
program anywhere it shouldn't be.

An ASPLOS paper from a few years ago discusses this problem and a
solution based on dynamic binary instrumentation using QEMU:

http://www.cs.ucsb.edu/~sherwood/pubs/ASPLOS-08-systemtomography.pdf

Among other things, I hope to address a number of deficiencies of
the tool described by that paper, in terms of efficiency (the other
sanitizer tools have shown that compiler-based instrumentation can be
much more efficient than binary instrumentation), and also in terms
of accuracy (unlike the system described in that paper, we track data
accurately through join points using union labels).

There are other applications outside of security.  For example,
one could use this instrumentation pass (or a variant of it) to tag
opposite-endian integers in memory, and check that no opposite-endian
integer is loaded or otherwise used directly without first going
through a conversion.

> Also, "sanitizer" may not be the best name for this, since it doesn't
> really sanitize anything.

As Reid mentioned, a goal is to build sanitizer-like tools on top of
this instrumentation.  Not only that, but one of the things that an
application can do is turn on its own sources and sinks in response
to the instrumentation being enabled (via the __has_feature macro).
So really, -fsanitize=dataflow would be the flag that turns on
data-flow sanitization for an application designed for it.  And should
the component of the compiler that allows this data-flow sanitization
be named any differently?

Thanks,
--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Bin Tzeng
It is interesting. I can see some use cases with such a tool. To me, source-level implementation
is not as accurate as binary translation. For instance, it is hard to check the taint for return addresses
since there is no concept of return instructions on source level. The stack does not appear until later.
For a security mechanism, return addresses need to be protected.

On Fri, Jun 14, 2013 at 10:43 AM, Peter Collingbourne <[hidden email]> wrote:
On Thu, Jun 13, 2013 at 03:13:37PM -0700, Sean Silva wrote:
> Could you maybe give some example use cases?

A use case I am interested in is to take a large application and use
this instrumentation as a tool to help monitor how data flows from its
inputs (sources) to its outputs (sinks).  This has applications from
a privacy/security perspective in that one can audit how a sensitive
data item is used within a program and ensure it isn't exiting the
program anywhere it shouldn't be.

An ASPLOS paper from a few years ago discusses this problem and a
solution based on dynamic binary instrumentation using QEMU:

http://www.cs.ucsb.edu/~sherwood/pubs/ASPLOS-08-systemtomography.pdf

Among other things, I hope to address a number of deficiencies of
the tool described by that paper, in terms of efficiency (the other
sanitizer tools have shown that compiler-based instrumentation can be
much more efficient than binary instrumentation), and also in terms
of accuracy (unlike the system described in that paper, we track data
accurately through join points using union labels).

There are other applications outside of security.  For example,
one could use this instrumentation pass (or a variant of it) to tag
opposite-endian integers in memory, and check that no opposite-endian
integer is loaded or otherwise used directly without first going
through a conversion.

> Also, "sanitizer" may not be the best name for this, since it doesn't
> really sanitize anything.

As Reid mentioned, a goal is to build sanitizer-like tools on top of
this instrumentation.  Not only that, but one of the things that an
application can do is turn on its own sources and sinks in response
to the instrumentation being enabled (via the __has_feature macro).
So really, -fsanitize=dataflow would be the flag that turns on
data-flow sanitization for an application designed for it.  And should
the component of the compiler that allows this data-flow sanitization
be named any differently?

Thanks,
--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Peter Collingbourne-2
This tool isn't for stack protection; there are other tools for that.
In general the tool isn't currently focused on defending against
adversaries -- it would be trivial to write a program that accesses
shadow memory directly in order to produce incorrect results, not
to mention "tag scrubbers" which use control flow to remove tags
(see section 6 of the ASPLOS paper).

On Fri, Jun 14, 2013 at 01:23:22PM -0700, Bin Tzeng wrote:

> It is interesting. I can see some use cases with such a tool. To me,
> source-level implementation
> is not as accurate as binary translation. For instance, it is hard to check
> the taint for return addresses
> since there is no concept of return instructions on source level. The stack
> does not appear until later.
> For a security mechanism, return addresses need to be protected.
>
> On Fri, Jun 14, 2013 at 10:43 AM, Peter Collingbourne <[hidden email]>wrote:
>
> > On Thu, Jun 13, 2013 at 03:13:37PM -0700, Sean Silva wrote:
> > > Could you maybe give some example use cases?
> >
> > A use case I am interested in is to take a large application and use
> > this instrumentation as a tool to help monitor how data flows from its
> > inputs (sources) to its outputs (sinks).  This has applications from
> > a privacy/security perspective in that one can audit how a sensitive
> > data item is used within a program and ensure it isn't exiting the
> > program anywhere it shouldn't be.
> >
> > An ASPLOS paper from a few years ago discusses this problem and a
> > solution based on dynamic binary instrumentation using QEMU:
> >
> > http://www.cs.ucsb.edu/~sherwood/pubs/ASPLOS-08-systemtomography.pdf
> >
> > Among other things, I hope to address a number of deficiencies of
> > the tool described by that paper, in terms of efficiency (the other
> > sanitizer tools have shown that compiler-based instrumentation can be
> > much more efficient than binary instrumentation), and also in terms
> > of accuracy (unlike the system described in that paper, we track data
> > accurately through join points using union labels).
> >
> > There are other applications outside of security.  For example,
> > one could use this instrumentation pass (or a variant of it) to tag
> > opposite-endian integers in memory, and check that no opposite-endian
> > integer is loaded or otherwise used directly without first going
> > through a conversion.
> >
> > > Also, "sanitizer" may not be the best name for this, since it doesn't
> > > really sanitize anything.
> >
> > As Reid mentioned, a goal is to build sanitizer-like tools on top of
> > this instrumentation.  Not only that, but one of the things that an
> > application can do is turn on its own sources and sinks in response
> > to the instrumentation being enabled (via the __has_feature macro).
> > So really, -fsanitize=dataflow would be the flag that turns on
> > data-flow sanitization for an application designed for it.  And should
> > the component of the compiler that allows this data-flow sanitization
> > be named any differently?
> >
> > Thanks,
> > --
> > Peter
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >

--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Sean Silva
In reply to this post by Peter Collingbourne-2
On Fri, Jun 14, 2013 at 10:43 AM, Peter Collingbourne <[hidden email]> wrote:

So really, -fsanitize=dataflow would be the flag that turns on
data-flow sanitization for an application designed for it.  And should
the component of the compiler that allows this data-flow sanitization
be named any differently?

Excellent point. I agree with your reasoning.

-- Sean Silva 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Peter Collingbourne-2
In reply to this post by Peter Collingbourne-2
On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote:
> Hi,
>
> I am starting a thread to discuss the design of DataFlowSanitizer,
> a compiler instrumentation based analysis tool which I am hoping to
> bring into LLVM.  As a starting point, I have included the current
> version of the design document below.  Comments are appreciated.

Any further comments on the below?  I've updated the design document
to add a use case at Kostya's request, but I'd appreciate any further
review of the design.

Thanks,
Peter


DataFlowSanitizer Design Document
*********************************

This document sets out the design for DataFlowSanitizer, a general
dynamic data flow analysis.  Unlike other Sanitizer tools, this tool
is not designed to detect a specific class of bugs on its own.
Instead, it provides a generic dynamic data flow analysis framework to
be used by clients to help detect application-specific issues within
their own code.

DataFlowSanitizer is a program instrumentation which can associate a
number of taint labels with any data stored in any memory region
accessible by the program. The analysis is dynamic, which means that
it operates on a running program, and tracks how the labels propagate
through that program. The tool shall support a large (>100) number of
labels, such that programs which operate on large numbers of data
items may be analysed with each data item being tracked separately.


Use Cases
=========

This instrumentation can be used as a tool to help monitor how data
flows from a program's inputs (sources) to its outputs (sinks). This
has applications from a privacy/security perspective in that one can
audit how a sensitive data item is used within a program and ensure it
isn't exiting the program anywhere it shouldn't be.


Interface
=========

A number of functions are provided which will create taint labels,
attach labels to memory regions and extract the set of labels
associated with a specific memory region. These functions are declared
in the header file "sanitizer/dfsan_interface.h".

   /// Creates and returns a base label with the given description and user data.
   dfsan_label dfsan_create_label(const char *desc, void *userdata);

   /// Sets the label for each address in [addr,addr+size) to \c label.
   void dfsan_set_label(dfsan_label label, void *addr, size_t size);

   /// Sets the label for each address in [addr,addr+size) to the union of the
   /// current label for that address and \c label.
   void dfsan_add_label(dfsan_label label, void *addr, size_t size);

   /// Retrieves the label associated with the given data.
   ///
   /// The type of 'data' is arbitrary.  The function accepts a value of any type,
   /// which can be truncated or extended (implicitly or explicitly) as necessary.
   /// The truncation/extension operations will preserve the label of the original
   /// value.
   dfsan_label dfsan_get_label(long data);

   /// Retrieves a pointer to the dfsan_label_info struct for the given label.
   const struct dfsan_label_info *dfsan_get_label_info(dfsan_label label);

   /// Returns whether the given label label contains the label elem.
   int dfsan_has_label(dfsan_label label, dfsan_label elem);

   /// If the given label label contains a label with the description desc, returns
   /// that label, else returns 0.
   dfsan_label dfsan_has_label_with_desc(dfsan_label label, const char *desc);


Taint label representation
==========================

As stated above, the tool must track a large number of taint labels.
This poses an implementation challenge, as most multiple-label
tainting systems assign one label per bit to shadow storage, and union
taint labels using a bitwise or operation. This will not scale to
clients which use hundreds or thousands of taint labels, as the label
union operation becomes O(n) in the number of supported labels, and
data associated with it will quickly dominate the live variable set,
causing register spills and hampering performance.

Instead, a low overhead approach is proposed which is best-case
O(log_2 n) during execution. The underlying assumption is that the
required space of label unions is sparse, which is a reasonable
assumption to make given that we are optimizing for the case where
applications mostly copy data from one place to another, without often
invoking the need for an actual union operation. The representation of
a taint label is a 16-bit integer, and new labels are allocated
sequentially from a pool. The label identifier 0 is special, and means
that the data item is unlabelled.

When a label union operation is requested at a join point (any
arithmetic or logical operation with two or more operands, such as
addition), the code checks whether a union is required, whether the
same union has been requested before, and whether one union label
subsumes the other. If so, it returns the previously allocated union
label. If not, it allocates a new union label from the same pool used
for new labels.

Specifically, the instrumentation pass will insert code like this to
decide the union label "lu" for a pair of labels "l1" and "l2":

   if (l1 == l2)
     lu = l1;
   else
     lu = __dfsan_union(l1, l2);

The equality comparison is outlined, to provide an early exit in the
common cases where the program is processing unlabelled data, or where
the two data items have the same label.  "__dfsan_union" is a runtime
library function which performs all other union computation.

Further optimizations are possible, for example if "l1" is known at
compile time to be zero (e.g. it is derived from a constant), "l2" can
be used for "lu", and vice versa.


Memory layout and label management
==================================

The following is the current memory layout for Linux/x86_64:

+-----------------+-----------------+----------------------+
| Start           | End             | Use                  |
+=================+=================+======================+
| 0x700000008000  | 0x800000000000  | application memory   |
+-----------------+-----------------+----------------------+
| 0x200200000000  | 0x700000008000  | unused               |
+-----------------+-----------------+----------------------+
| 0x200000000000  | 0x200200000000  | union table          |
+-----------------+-----------------+----------------------+
| 0x000000010000  | 0x200000000000  | shadow memory        |
+-----------------+-----------------+----------------------+
| 0x000000000000  | 0x000000010000  | reserved by kernel   |
+-----------------+-----------------+----------------------+

Each byte of application memory corresponds to two bytes of shadow
memory, which are used to store its taint label. As for LLVM SSA
registers, we have not found it necessary to associate a label with
each byte or bit of data, as some other tools do. Instead, labels are
associated directly with registers.  Loads will result in a union of
all shadow labels corresponding to bytes loaded (which most of the
time will be short circuited by the initial comparison) and stores
will result in a copy of the label to the shadow of all bytes stored
to.

--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Peter Collingbourne-2
Hi,

If there are no further comments on the design below I intend to commit
my DFSan patches in a week.

Thanks,
Peter

On Tue, Jun 25, 2013 at 06:13:49PM -0700, Peter Collingbourne wrote:

> On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote:
> > Hi,
> >
> > I am starting a thread to discuss the design of DataFlowSanitizer,
> > a compiler instrumentation based analysis tool which I am hoping to
> > bring into LLVM.  As a starting point, I have included the current
> > version of the design document below.  Comments are appreciated.
>
> Any further comments on the below?  I've updated the design document
> to add a use case at Kostya's request, but I'd appreciate any further
> review of the design.
>
> Thanks,
> Peter
>
>
> DataFlowSanitizer Design Document
> *********************************
>
> This document sets out the design for DataFlowSanitizer, a general
> dynamic data flow analysis.  Unlike other Sanitizer tools, this tool
> is not designed to detect a specific class of bugs on its own.
> Instead, it provides a generic dynamic data flow analysis framework to
> be used by clients to help detect application-specific issues within
> their own code.
>
> DataFlowSanitizer is a program instrumentation which can associate a
> number of taint labels with any data stored in any memory region
> accessible by the program. The analysis is dynamic, which means that
> it operates on a running program, and tracks how the labels propagate
> through that program. The tool shall support a large (>100) number of
> labels, such that programs which operate on large numbers of data
> items may be analysed with each data item being tracked separately.
>
>
> Use Cases
> =========
>
> This instrumentation can be used as a tool to help monitor how data
> flows from a program's inputs (sources) to its outputs (sinks). This
> has applications from a privacy/security perspective in that one can
> audit how a sensitive data item is used within a program and ensure it
> isn't exiting the program anywhere it shouldn't be.
>
>
> Interface
> =========
>
> A number of functions are provided which will create taint labels,
> attach labels to memory regions and extract the set of labels
> associated with a specific memory region. These functions are declared
> in the header file "sanitizer/dfsan_interface.h".
>
>    /// Creates and returns a base label with the given description and user data.
>    dfsan_label dfsan_create_label(const char *desc, void *userdata);
>
>    /// Sets the label for each address in [addr,addr+size) to \c label.
>    void dfsan_set_label(dfsan_label label, void *addr, size_t size);
>
>    /// Sets the label for each address in [addr,addr+size) to the union of the
>    /// current label for that address and \c label.
>    void dfsan_add_label(dfsan_label label, void *addr, size_t size);
>
>    /// Retrieves the label associated with the given data.
>    ///
>    /// The type of 'data' is arbitrary.  The function accepts a value of any type,
>    /// which can be truncated or extended (implicitly or explicitly) as necessary.
>    /// The truncation/extension operations will preserve the label of the original
>    /// value.
>    dfsan_label dfsan_get_label(long data);
>
>    /// Retrieves a pointer to the dfsan_label_info struct for the given label.
>    const struct dfsan_label_info *dfsan_get_label_info(dfsan_label label);
>
>    /// Returns whether the given label label contains the label elem.
>    int dfsan_has_label(dfsan_label label, dfsan_label elem);
>
>    /// If the given label label contains a label with the description desc, returns
>    /// that label, else returns 0.
>    dfsan_label dfsan_has_label_with_desc(dfsan_label label, const char *desc);
>
>
> Taint label representation
> ==========================
>
> As stated above, the tool must track a large number of taint labels.
> This poses an implementation challenge, as most multiple-label
> tainting systems assign one label per bit to shadow storage, and union
> taint labels using a bitwise or operation. This will not scale to
> clients which use hundreds or thousands of taint labels, as the label
> union operation becomes O(n) in the number of supported labels, and
> data associated with it will quickly dominate the live variable set,
> causing register spills and hampering performance.
>
> Instead, a low overhead approach is proposed which is best-case
> O(log_2 n) during execution. The underlying assumption is that the
> required space of label unions is sparse, which is a reasonable
> assumption to make given that we are optimizing for the case where
> applications mostly copy data from one place to another, without often
> invoking the need for an actual union operation. The representation of
> a taint label is a 16-bit integer, and new labels are allocated
> sequentially from a pool. The label identifier 0 is special, and means
> that the data item is unlabelled.
>
> When a label union operation is requested at a join point (any
> arithmetic or logical operation with two or more operands, such as
> addition), the code checks whether a union is required, whether the
> same union has been requested before, and whether one union label
> subsumes the other. If so, it returns the previously allocated union
> label. If not, it allocates a new union label from the same pool used
> for new labels.
>
> Specifically, the instrumentation pass will insert code like this to
> decide the union label "lu" for a pair of labels "l1" and "l2":
>
>    if (l1 == l2)
>      lu = l1;
>    else
>      lu = __dfsan_union(l1, l2);
>
> The equality comparison is outlined, to provide an early exit in the
> common cases where the program is processing unlabelled data, or where
> the two data items have the same label.  "__dfsan_union" is a runtime
> library function which performs all other union computation.
>
> Further optimizations are possible, for example if "l1" is known at
> compile time to be zero (e.g. it is derived from a constant), "l2" can
> be used for "lu", and vice versa.
>
>
> Memory layout and label management
> ==================================
>
> The following is the current memory layout for Linux/x86_64:
>
> +-----------------+-----------------+----------------------+
> | Start           | End             | Use                  |
> +=================+=================+======================+
> | 0x700000008000  | 0x800000000000  | application memory   |
> +-----------------+-----------------+----------------------+
> | 0x200200000000  | 0x700000008000  | unused               |
> +-----------------+-----------------+----------------------+
> | 0x200000000000  | 0x200200000000  | union table          |
> +-----------------+-----------------+----------------------+
> | 0x000000010000  | 0x200000000000  | shadow memory        |
> +-----------------+-----------------+----------------------+
> | 0x000000000000  | 0x000000010000  | reserved by kernel   |
> +-----------------+-----------------+----------------------+
>
> Each byte of application memory corresponds to two bytes of shadow
> memory, which are used to store its taint label. As for LLVM SSA
> registers, we have not found it necessary to associate a label with
> each byte or bit of data, as some other tools do. Instead, labels are
> associated directly with registers.  Loads will result in a union of
> all shadow labels corresponding to bytes loaded (which most of the
> time will be short circuited by the initial comparison) and stores
> will result in a copy of the label to the shadow of all bytes stored
> to.
>
> --
> Peter

--
Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Chandler Carruth-2
On Tue, Aug 6, 2013 at 5:55 PM, Peter Collingbourne <[hidden email]> wrote:
Hi,

If there are no further comments on the design below I intend to commit
my DFSan patches in a week.

I think it would be good to get Kostya's explicit sign-off on this before committing it, as he has been directing and overseeing the sanitizer work as a whole over the past year. CC-ing him directly to see if he can take time to look through this. I think he's back from vacation at this point.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Kostya Serebryany
I've seen the following patches, and I am ok with them: 
http://llvm-reviews.chandlerc.com/D966 (clang driver, design doc) -- LGTM
https://codereview.googleplex.com/204001 (then http://llvm-reviews.chandlerc.com/D967) (compiler-rt) -- LGTM (synchronization part also reviewed by dvyukov@)
http://llvm-reviews.chandlerc.com/D965 (llvm) -- LGTM-ed by eugenis@

--kcc 




On Wed, Aug 7, 2013 at 5:00 AM, Chandler Carruth <[hidden email]> wrote:
On Tue, Aug 6, 2013 at 5:55 PM, Peter Collingbourne <[hidden email]> wrote:
Hi,

If there are no further comments on the design below I intend to commit
my DFSan patches in a week.

I think it would be good to get Kostya's explicit sign-off on this before committing it, as he has been directing and overseeing the sanitizer work as a whole over the past year. CC-ing him directly to see if he can take time to look through this. I think he's back from vacation at this point.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Konstantin Tokarev
In reply to this post by Bin Tzeng

15.06.2013, 00:53, "Bin Tzeng" <[hidden email]>:
> It is interesting. I can see some use cases with such a tool. To me, source-level implementation
> is not as accurate as binary translation. For instance, it is hard to check the taint for return addresses
> since there is no concept of return instructions on source level.

Well, on many architectures there is no concept of return instruction on ISA level too :)

--
Regards,
Konstantin
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DataFlowSanitizer design discussion

Bin Tzeng
That is true. I was referring to the program counter on ISA level. C/C++ abstractions do not expose that. It is not the intended use case for DFSan I guess. ;]


On Wed, Aug 7, 2013 at 8:01 AM, Konstantin Tokarev <[hidden email]> wrote:

15.06.2013, 00:53, "Bin Tzeng" <[hidden email]>:
> It is interesting. I can see some use cases with such a tool. To me, source-level implementation
> is not as accurate as binary translation. For instance, it is hard to check the taint for return addresses
> since there is no concept of return instructions on source level.

Well, on many architectures there is no concept of return instruction on ISA level too :)

--
Regards,
Konstantin


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev