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

Powered by blists - more mailing lists