new qos_clock crate and boot-time kvm-clock validation

[emostov]

Summary & Motivation (Problem vs. Solution)

This is meant to demonstrate how we could ensure we are using the kvm-clock.
This article discusses why the KVM clock https://blog.trailofbits.com/2024/09/24/notes-on-aws-nitro-enclaves-attack-surface/#time

Specifically

• Ensure that current_clocksource is set to kvm-clock in the enclave’s kernel configuration; consider even adding an application-level runtime check for the clock (in case something goes wrong during enclave bootstrapping and it ends up with a different clock source).
• Enable the Precision Time Protocol for better clock synchronization between the enclave and the hypervisor. It’s like the Network Time Protocol (NTP) but works over a hardware connection. It should be more secure (as it has a smaller attack surface) and easier to set up than the NTP.
• For security-critical functionalities (like replay protections) use Unix time. Be careful with UTC and time zones, as daylight saving time and leap seconds may “move time backwards.”

Note this does not cover configuring PTP synchronization. This must be done on the parent ec2 instance

How I Tested These Changes

Pre merge check list

• Call out updates and breaking changes via conventional commits
• Communicate verification flow breaking changes especially thoroughly. If any of the following answers are no, then this is a verification flow breaking change:
  • Can enclaves in a previous QOS version still key forward to this new version?
  • Can previous versions of QOS verify attestations from this new version?
  • Can manifests generated by a previous version still be parsed by this one?
  • Can previous approvals still be verified against a manifest (i.e. is this a non-breaking change to the manifest signing payload)?
  • Can a previous version of QOS still perform a boot standard on an enclave of this version?

[emostov]

Realistically we could get around needing a trait and just use SystemTime::now().duration_since(SystemTime::UNIX_EPOCH). But trait might be useful for testing when we want to control time

[richardpringle]

The default implementation for SystemTime is inefficient... it's already a u64
https://doc.rust-lang.org/stable/src/core/time.rs.html#506