Provide taint frameworks compatibility layer

[ivg]

Now we have two approaches to taint analysis:

• The new Taint Analysis Framework
• The legacy Taint Propagation Framework

While the former is more precise and versatile then the latter we
still have a bunch of legacy software that we want to support, e.g.,
Saluki and our IDA Pro integration still relies on the old
framework. We may update the downstream tools to use the new
Taint Analysis Framework, but right now we don't have enough recourses
to perform such task. And I doubt that in case of Saluki this will make
any sense.

The primus-propagate-taint plugin provides a compatibility layer that
allows legacy tools to benefit from Primus without event knowing
anything about it. There are some trade-offs starting from the
semantics of the propagation and ending with the desire to minimize
breaking changes in bap command line interface, that are explained in
detail in the man page of the plugin (provided below for the
reference):

DESCRIPTION
       This plugin implements a compatibility layer between the new Primus
       Taint Analysis Framework and the old taint propagation framework (the
       propagate-taint plugin). The new framework uses the
       pubslisher-subscriber pattern, provides sanitization operations, and
       tracks the taints liveness, that enables more conventional and online
       taint analysis. However it represents taints as abstract objects
       associated with computations (values), while the old taint propagation
       framework uses a pipeline approach, with taints represented as
       attributes attached to program terms. Since the new representation of
       taints is much more precise and there is no bijection between terms and
       values, this layer will loose information due to this impendance
       mismatch. The trade-offs of the translation and described below. New
       analysis, if possible, shall rely on the new framework.

       The translation is achieved by mapping the tainted-ptr and tainted-reg
       attributes to corresponding taint introduction operations of the Primus
       Taint Analysis Framework, and by reflecting the taint state of the
       analysis into the tainted-regs and tainted-ptrs attributes. Both steps
       are optional, and could be enabled and disabled individually.

       Since an attribute is attached to the whole term not to an individual
       expression or value we need some rule that prescribes how terms maps to
       values. If a term is marked as a term that introduces a taint, then we
       assume that a value, computed in this term, references the tainted
       object either directly (in case of tainted-reg) or indirectly (in case
       of tainted-ptr). We always taint a value contained in the left-hand
       side of a definition. In addition, we also try to taint values on the
       right hand side. If there is a load or store operation, then we taint
       address as a pointer to the object that will track, if it was marked
       with the tainted-reg attribute. If it was marked with the tainted-ptr
       attribute then we dereference this pointer and taint the dereferenced
       address. If the right hand side is an abritrary expression, then we
       assume that all variables that are used in this expression contain
       values that are referencing directly or indirectly the tainted object.

OPTIONS
       --from-attributes
           Introduces taint in terms that are marked with the tainted-ptr and
           tainted-reg attribute.

       --help[=FMT] (default=auto)
           Show this help in format FMT. The value FMT must be one of `auto',
           `pager', `groff' or `plain'. With `auto', the format is `pager` or
           `plain' whenever the TERM env var is `dumb' or undefined.

       --no-marks
           Disables the projection of the taint engine state to term
           attributes. The option is only valid when the run option is
           specified. This option is left for compatibility with the old
           interface and is not compatible with the from-attributes or
           to-attrbutes options. It is an error to mix options from the new
           and old interfaces.

       --run
           Enables propagating taint from term attributes and back to
           attributes, unless the latter is disabled with the no-marks option.
           This option is left for compatibility with the old interface and is
           not compatible with the from-attributes or to-attrbutes options. It
           is an error to mix options from the new and old interfaces.

       --to-attributes
           Reflects the state of the taint propagation engine to the
           tainted-ptrs and tainted-regs term attributes.

If you read that far, then you deserve the bonus track, this is how we
can run Saluki using the new Taint Analysis Framework as a taint
propagation engine:

bap ./exe --saluki-print-models --propagate-taint-print-coverage \
  	  --passes=trivial-condition-form,saluki-taint,run,saluki-solve \
	  --primus-propagate-taint-from-attr --primus-propagate-taint-to-attr \
	  --primus-promiscuous-mode --primus-greedy-scheduler \
	  --primus-limit-max-visited=64 --primus-limit-max-length=4096

Yep, that's scary... I will later provide a recipe, and will also update
Saluki's Makefile to facilitate Saluki experimentation with the new
engine.

need to fix mem taint

[gitoleg]

here we taint lhs part, that is not completely correct in case of store: we taint a whole memory in this case.
So we should ignore explicitly memory taints.