Add threat model documentation

[andreeaflorescu]

Adding a threat model should be pretty straight forward for this repository, and should follow the KVM threat model (is there such a thing generally available? ping @bonzini).

Since this is just a proxy repository that forwards calls to KVM, we should talk about:

• who is calling the ioctls (is it trusted/untrusted)
• ioctls input
• ioctls output

Another interesting thing is to call out the unsafe function and use of raw pointers as these might lead to undefined behaviors.

[stevenrutherford]

I'm not sure there is a written up threat model for KVM. The closest thing I can think of is Andrew Honig's KVM Forum talk (related). Since this talk was in 2014, it does not cover more recent changes to the threat model (e.g. l1tf/speculation, confidential compute, nested).

A summary (ignoring SEV/TDX/...) would be something like:

The VM cannot:

• Read arbitrary kernel/VMM memory.
• Write arbitrary kernel/VMM memory.
• Escape into the kernel/VMM.
• DoS the host or other guests.

The VMM will ensure the VM:

• Can rely on CPU behavior it expects from real hardware.
• (sub-bullet) Can provide that same reliability to it's own guests, when nesting.

Users of KVM cannot:

• Read arbitrary kernel memory.
• Write arbitrary kernel memory.
• Escalate into the kernel.
• DoS the host or other processes.
• ... and the rest of Linux threat model

For this crate, the "normal" Linux threat model is probably the one to take on. At that, this crate should likely ignore the implications of speculation issues. This crate probably shouldn't have to think about which CPU it's on and if you have hyperthreading enabled. That's the job of the caller.

[andreeaflorescu]

@stevenrutherford thanks for the information. I'll be taking a look at the talk you mentioned!