anchor.diff:  [[green-field]]
   ## Green-field deployment step-by-step
   
  +NOTE: This section needs updating after the change to personal recovery keys
  +and updates on the trust chain.
  +
   This section will run through the full set of steps needed to deploy Triton
   with full RFD 77 security enabled.
   
  
positive.code: pieces being held).
  
  If the pieces are stored in separate geographic locations with separate access
  controls, this can enable a form of the "2-person rule" to be enforced, where
  these valuable "master" keys can only be used with the co-operation of multiple
  trusted members of the organization.
  
  The scheme we propose is as follows:
  
   * Generation and preparation of the root key and recovery keys will take place
     in an environment away from the data center, and will be done in advance by
     administrators.
   * The administrators must initialize backup media that have been chosen to
     store the backed up key pieces. Initializing the media writes metadata to
     it describing its contents and purpose.
   * The root and recovery keys will both be split into 3 pieces, in a Shamir
     arrangement requiring 2 pieces for recovery. Each of the pieces will be
     written to separate media.
   * The media may then be stored in a secure location (e.g. a safe).
   * The public keys and initial headnode trust chain can then be written to the
     boot USB flash media for the initial headnodes, and transported to the
     datacenter as part of the deployment process.
      - As an alternative, the headnode setup process will accept the public keys
        and trust chain root on the console.
  
  This scheme will be implemented using a set of tools that can run on at least
  
negative.code: cannot be flushed out (containing both the code and data used in the sensitive
  operation).
  
  At the same time, we plan to make use of improvements in hyperthread scheduling
  to avoid sharing any L1 cache between soft-tokens or between soft-tokens and
  customer workloads.
  
  Soft-token processes also will not share any memory pages (including code pages)
  with each other or any other part of the system -- this is aided by an operating
  system facility to mark binaries and shared objects are "unshared" so that they
  are always duplicated into each process that maps them. KSM (kernel same-page
  merging) and other similar mechanisms are not (and will not be) supported by
  illumos.
  
  As well as this direct mitigation, the algorithms chosen (see the
  <<crypto-algos>> section) for soft-token usage are chosen with side-channel
  leak prevention in mind.
  
  The chosen algorithms combined with these mitigation techniques should prevent
  most known mechanisms of memory timing side-channel leakage from the
  cryptographic algorithms run in the soft-token, including Flush+Reload and
  other related attacks.
  
  [[hardware]]
  ## Hardware implementation
  