On 09/13/2017 01:37 PM, Borislav Petkov wrote:
On Wed, Sep 13, 2017 at 01:23:08PM -0500, Brijesh Singh wrote:
Yes, I will add some upper bound check on the length field and add the
sanity-check just after copying the parameters from userspace
Also, you could either fail the command if some of the reserved fields
are set - picky - or zero them out - less picky :)
Actually reversed fields are not exposed in userspace structure.
e.g a LAUNCH_UPDATE_DATE userspace structure looks like this:
struct kvm_sev_launch_update_data {
__u64 address; /* userspace address of memory region to encrypt */
__u32 length; /* length of memory region to encrypt */
};
But SEV firmware command structure is a slightly different (mainly it contains
the reserved field and firmware handle etc).
/**
* struct sev_data_launch_update_data - LAUNCH_UPDATE_DATA command parameter
*
* @handle: firmware handle to use
* @length: length of memory to be encrypted
* @address: physical address of memory region to encrypt
*/
struct sev_data_launch_update_data {
u32 handle; /* In */
u32 reserved;
u64 address; /* In */
u32 length; /* In */
};
Please note that some commands require us passing the VM ASID etc --
userspace does not have VM ASID information.
The current approach is -- while handling the command we copy the value
from userspace structure into FW compatible structure and also populate
missing fields which are not known to userspace (e.g firmware handle,
VM ASID, use system physical addresses etc).
