linux-kernel - Re: [RFC Part2 PATCH v3 15/26] KVM: SVM: Add support for SEV LAUNCH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3b071fe-5d5f-3220-cba1-d55765094c24@amd.com>
Date:   Wed, 13 Sep 2017 13:58:31 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     brijesh.singh@....com, linux-kernel@...r.kernel.org,
        x86@...nel.org, kvm@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Joerg Roedel <joro@...tes.org>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        \"Radim Krčmář\" <rkrcmar@...hat.com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC Part2 PATCH v3 15/26] KVM: SVM: Add support for SEV
 LAUNCH_START command



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).