Skip to content
  1. Dec 22, 2017
  2. Dec 21, 2017
    • Yurii Rashkovskii's avatar
      Problem: AuRa's unsafeties around step duration (#7282) · d5b81ead
      Yurii Rashkovskii authored
      Firstly, `Step.duration_remaining` casts it to u32, unnecesarily
      limiting it to 2^32. While theoretically this is "good enough" (at 3
      seconds steps it provides room for a little over 400 years), it is
      still a lossy way to calculate the remaining time until the next step.
      
      Secondly, step duration might be zero, triggering division by zero
      in `Step.calibrate`
      
      Solution: rework the code around the fact that duration is
      typically in single digits and never grows, hence, it can be represented
      by a much narrower range (u16) and this highlights the fact that
      multiplying u64 by u16 will only result in an overflow in even further
      future, at which point we should panic informatively (if anybody's
      still around)
      
      Similarly, panic when it is detected that incrementing the step
      counter wrapped around on the overflow of usize.
      
      As for the division by zero, prevent it by making zero an invalid
      value for step duration. This will make AuRa log the constraint
      mismatch and panic (after all, what purpose would zero step duration
      serve? it makes no sense within the definition of the protocol,
      as finality can only be achieved as per the specification
      if messages are received within the step duration, which would violate
      the speed of light and other physical laws in this case).
      d5b81ead
  3. Dec 20, 2017
  4. Dec 19, 2017
  5. Dec 18, 2017
  6. Dec 15, 2017
  7. Dec 14, 2017
  8. Dec 13, 2017
  9. Dec 12, 2017