anchor.diff:  round trips through a (rate-limited) hardware module in order to decrypt them.
   If the attacker compromises an entire live Triton CN (including the contents of
   RAM) with M zones on it, they should have no choice but to make at least M round
  -trips through a hardware module in order to access customer data so protected.
  +trips through a hardware module (or perform computation taking at least as long)
  +in order to access customer data so protected.
  +
  +NOTE:: Goal 3 explicitly does not include absolute defense of this data against
  +an attacker who has complete control of the OS kernel for an abitrarily long
  +period. It *does*, however, set a minimum amount of time an attacker must be
  +present with such control in order to break the security of protected storage on
  +the machine: the attacker must spend at least as long there as it would take to
  +make N trips through the hardware module.
   
   ## Design
   
  
positive.code: CN:: A "CN" here is any physical node in the Triton system.
  Trusted CN:: A "trusted" CN is one that is trusted to run components of the
  Triton system itself (e.g. VMAPI, NAPI, CloudAPI etc)
  Self-booting CN:: A "self-booting" CN is one that can boot entirely standalone,
  without any other machine in the datacenter or network access being available.
  Headnode:: A "headnode" is a term for a CN that is both trusted and
  self-booting. Any Triton datacenter needs to have at least one such node.
  
  ## Threat models and goals
  
  
negative.code: cannot take any actions that would escalate or allow sideways movement into
  other CNs.
  
  Threat 3:: An intruder has taken control of a public-facing core service
  (e.g. CloudAPI), by making use of a vulnerability in that service.
  Goal 3:: The goal is to give this attacker only the minimum access required by
  the normal operation of that service. This means, for example, that CloudAPI
  