From: Venu Busireddy <venu.busireddy@oracle.com>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: Ashish Kalra <Ashish.Kalra@amd.com>,
pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, joro@8bytes.org, bp@suse.de,
thomas.lendacky@amd.com, x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, rientjes@google.com,
srutherford@google.com, luto@kernel.org
Subject: Re: [PATCH v6 01/14] KVM: SVM: Add KVM_SEV SEND_START command
Date: Thu, 2 Apr 2020 14:43:13 -0500 [thread overview]
Message-ID: <20200402194313.GA656773@vbusired-dt> (raw)
In-Reply-To: <6ced22f7-cbe5-a698-e650-7716566d4d8a@amd.com>
On 2020-04-02 14:17:26 -0500, Brijesh Singh wrote:
>
> On 4/2/20 1:57 PM, Venu Busireddy wrote:
> [snip]...
>
> >> The question is, how does a userspace know the session length ? One
> >> method is you can precalculate a value based on your firmware version
> >> and have userspace pass that, or another approach is set
> >> params.session_len = 0 and query it from the FW. The FW spec allow to
> >> query the length, please see the spec. In the qemu patches I choose
> >> second approach. This is because session blob can change from one FW
> >> version to another and I tried to avoid calculating or hardcoding the
> >> length for a one version of the FW. You can certainly choose the first
> >> method. We want to ensure that kernel interface works on the both cases.
> > I like the fact that you have already implemented the functionality to
> > facilitate the user space to obtain the session length from the firmware
> > (by setting params.session_len to 0). However, I am trying to address
> > the case where the user space sets the params.session_len to a size
> > smaller than the size needed.
> >
> > Let me put it differently. Let us say that the session blob needs 128
> > bytes, but the user space sets params.session_len to 16. That results
> > in us allocating a buffer of 16 bytes, and set data->session_len to 16.
> >
> > What does the firmware do now?
> >
> > Does it copy 128 bytes into data->session_address, or, does it copy
> > 16 bytes?
> >
> > If it copies 128 bytes, we most certainly will end up with a kernel crash.
> >
> > If it copies 16 bytes, then what does it set in data->session_len? 16,
> > or 128? If 16, everything is good. If 128, we end up causing memory
> > access violation for the user space.
>
> My interpretation of the spec is, if user provided length is smaller
> than the FW expected length then FW will reports an error with
> data->session_len set to the expected length. In other words, it should
> *not* copy anything into the session buffer in the event of failure.
That is good, and expected behavior.
> If FW is touching memory beyond what is specified in the session_len then
> its FW bug and we can't do much from kernel.
Agreed. But let us assume that the firmware is not touching memory that
it is not supposed to.
> Am I missing something ?
I believe you are agreeing that if the session blob needs 128 bytes and
user space sets params.session_len to 16, the firmware does not copy
any data to data->session_address, and sets data->session_len to 128.
Now, when we return, won't the user space try to access 128 bytes
(params.session_len) of data in params.session_uaddr, and crash? Because,
instead of returning an error that buffer is not large enough, we return
the call successfully!
That is why I was suggesting the following, which you seem to have
missed.
> > Perhaps, this can be dealt a little differently? Why not always call
> > sev_issue_cmd(kvm, SEV_CMD_SEND_START, ...) with zeroed out data? Then,
> > if the user space has set params.session_len to 0, we return with the
> > needed params.session_len. Otherwise, we check if params.session_len is
> > large enough, and if not, we return -EINVAL?
Doesn't the above approach address all scenarios?
next prev parent reply other threads:[~2020-04-02 19:43 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 6:19 [PATCH v6 00/14] Add AMD SEV guest live migration support Ashish Kalra
2020-03-30 6:19 ` [PATCH v6 01/14] KVM: SVM: Add KVM_SEV SEND_START command Ashish Kalra
2020-04-02 6:27 ` Venu Busireddy
2020-04-02 12:59 ` Brijesh Singh
2020-04-02 16:37 ` Venu Busireddy
2020-04-02 18:04 ` Brijesh Singh
2020-04-02 18:57 ` Venu Busireddy
2020-04-02 19:17 ` Brijesh Singh
2020-04-02 19:43 ` Venu Busireddy [this message]
2020-04-02 20:04 ` Brijesh Singh
2020-04-02 20:19 ` Venu Busireddy
2020-04-02 17:51 ` Krish Sadhukhan
2020-04-02 18:38 ` Brijesh Singh
2020-03-30 6:20 ` [PATCH v6 02/14] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Ashish Kalra
2020-04-02 17:55 ` Venu Busireddy
2020-04-02 20:13 ` Krish Sadhukhan
2020-03-30 6:20 ` [PATCH v6 03/14] KVM: SVM: Add KVM_SEV_SEND_FINISH command Ashish Kalra
2020-04-02 18:17 ` Venu Busireddy
2020-04-02 20:15 ` Krish Sadhukhan
2020-03-30 6:21 ` [PATCH v6 04/14] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Ashish Kalra
2020-04-02 21:35 ` Venu Busireddy
2020-04-02 22:09 ` Krish Sadhukhan
2020-03-30 6:21 ` [PATCH v6 05/14] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Ashish Kalra
2020-04-02 22:25 ` Krish Sadhukhan
2020-04-02 22:29 ` Venu Busireddy
2020-04-07 0:49 ` Steve Rutherford
2020-03-30 6:21 ` [PATCH v6 06/14] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Ashish Kalra
2020-04-02 22:24 ` Venu Busireddy
2020-04-02 22:27 ` Krish Sadhukhan
2020-04-07 0:57 ` Steve Rutherford
2020-03-30 6:21 ` [PATCH v6 07/14] KVM: x86: Add AMD SEV specific Hypercall3 Ashish Kalra
2020-04-02 22:36 ` Venu Busireddy
2020-04-02 23:54 ` Krish Sadhukhan
2020-04-07 1:22 ` Steve Rutherford
2020-03-30 6:22 ` [PATCH v6 08/14] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Ashish Kalra
2020-04-03 0:00 ` Venu Busireddy
2020-04-03 1:31 ` Krish Sadhukhan
2020-04-03 1:57 ` Ashish Kalra
2020-04-03 2:58 ` Ashish Kalra
2020-04-06 22:27 ` Krish Sadhukhan
2020-04-07 2:17 ` Steve Rutherford
2020-04-07 5:27 ` Ashish Kalra
2020-04-08 0:01 ` Steve Rutherford
2020-04-08 0:29 ` Brijesh Singh
2020-04-08 0:35 ` Steve Rutherford
2020-04-08 1:17 ` Ashish Kalra
2020-04-08 1:38 ` Steve Rutherford
2020-04-08 2:34 ` Brijesh Singh
2020-04-08 3:18 ` Ashish Kalra
2020-04-09 16:18 ` Ashish Kalra
2020-04-09 20:41 ` Steve Rutherford
2020-03-30 6:22 ` [PATCH v6 09/14] KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl Ashish Kalra
2020-04-03 18:30 ` Venu Busireddy
2020-04-03 20:18 ` Krish Sadhukhan
2020-04-03 20:47 ` Ashish Kalra
2020-04-06 22:07 ` Krish Sadhukhan
2020-04-03 20:55 ` Venu Busireddy
2020-04-03 21:01 ` Ashish Kalra
2020-03-30 6:22 ` [PATCH v6 10/14] mm: x86: Invoke hypercall when page encryption status is changed Ashish Kalra
2020-04-03 21:07 ` Krish Sadhukhan
2020-04-03 21:30 ` Ashish Kalra
2020-04-03 21:36 ` Venu Busireddy
2020-03-30 6:22 ` [PATCH v6 11/14] KVM: x86: Introduce KVM_SET_PAGE_ENC_BITMAP ioctl Ashish Kalra
2020-04-03 21:10 ` Krish Sadhukhan
2020-04-03 21:46 ` Venu Busireddy
2020-04-08 0:26 ` Steve Rutherford
2020-04-08 1:48 ` Ashish Kalra
2020-04-10 0:06 ` Steve Rutherford
2020-04-10 1:23 ` Ashish Kalra
2020-04-10 18:08 ` Steve Rutherford
2020-03-30 6:23 ` [PATCH v6 12/14] KVM: x86: Introduce KVM_PAGE_ENC_BITMAP_RESET ioctl Ashish Kalra
2020-04-03 21:14 ` Krish Sadhukhan
2020-04-03 21:45 ` Ashish Kalra
2020-04-06 18:52 ` Krish Sadhukhan
2020-04-08 1:25 ` Steve Rutherford
2020-04-08 1:52 ` Ashish Kalra
2020-04-10 0:59 ` Steve Rutherford
2020-04-10 1:34 ` Ashish Kalra
2020-04-10 18:14 ` Steve Rutherford
2020-04-10 20:16 ` Steve Rutherford
2020-04-10 20:18 ` Steve Rutherford
2020-04-10 20:55 ` Kalra, Ashish
2020-04-10 21:42 ` Brijesh Singh
2020-04-10 21:46 ` Sean Christopherson
2020-04-10 21:58 ` Brijesh Singh
2020-04-10 22:02 ` Brijesh Singh
2020-04-11 0:35 ` Ashish Kalra
2020-04-03 22:01 ` Venu Busireddy
2020-03-30 6:23 ` [PATCH v6 13/14] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR Ashish Kalra
2020-03-30 15:52 ` Brijesh Singh
2020-03-30 16:42 ` Ashish Kalra
[not found] ` <20200330162730.GA21567@ashkalra_ubuntu_server>
[not found] ` <1de5e95f-4485-f2ff-aba8-aa8b15564796@amd.com>
[not found] ` <20200331171336.GA24050@ashkalra_ubuntu_server>
[not found] ` <20200401070931.GA8562@ashkalra_ubuntu_server>
2020-04-02 23:29 ` Ashish Kalra
2020-04-03 23:46 ` Krish Sadhukhan
2020-03-30 6:23 ` [PATCH v6 14/14] KVM: x86: Add kexec support for SEV Live Migration Ashish Kalra
2020-03-30 16:00 ` Brijesh Singh
2020-03-30 16:45 ` Ashish Kalra
2020-03-31 14:26 ` Brijesh Singh
2020-04-02 23:34 ` Ashish Kalra
2020-04-03 12:57 ` Dave Young
2020-04-04 0:55 ` Krish Sadhukhan
2020-04-04 21:57 ` Ashish Kalra
2020-04-06 18:37 ` Krish Sadhukhan
2020-03-30 17:24 ` [PATCH v6 00/14] Add AMD SEV guest live migration support Venu Busireddy
2020-03-30 18:28 ` Ashish Kalra
2020-03-30 19:13 ` Venu Busireddy
2020-03-30 21:52 ` Ashish Kalra
2020-03-31 14:42 ` Venu Busireddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200402194313.GA656773@vbusired-dt \
--to=venu.busireddy@oracle.com \
--cc=Ashish.Kalra@amd.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rientjes@google.com \
--cc=srutherford@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).