From: "Singh, Brijesh" <brijesh.singh@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command
Date: Mon, 29 Apr 2019 15:01:24 +0000 [thread overview]
Message-ID: <2b63d983-a622-3bec-e6ac-abfd024e19c0@amd.com> (raw)
In-Reply-To: <20190426204327.GM4608@zn.tnic>
On 4/26/19 3:43 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 02:29:31PM +0000, Singh, Brijesh wrote:
>> Yes that's doable but I am afraid that caching the value may lead us to
>> wrong path and also divergence from the SEV API spec. The spec says the
>> returned length is a minimum length but its possible that caller can
>> give a bigger buffer and FW will still work with it.
>
> Does the caller even have a valid reason to give a bigger buffer len?
>
Practically I don't see any reason why caller would do that but
theoretically it can. If we cache the len then we also need to consider
adding another flag to hint whether userspace ever requested length.
e.g an application can compute the length of session blob by looking at
the API version and spec and may never query the length.
> I mean I'm still thinking defensively here but maybe the only thing that
> would happen here with a bigger buffer is if the kmalloc() would fail,
> leading to eventual failure of the migration.
>
> If the code limits the allocation to some sane max length, the migration
> won't fail even if userspace gives it too big values...
>
WARNING: multiple messages have this Message-ID (diff)
From: "Singh, Brijesh" <brijesh.singh@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Qemu-devel] [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command
Date: Mon, 29 Apr 2019 15:01:24 +0000 [thread overview]
Message-ID: <2b63d983-a622-3bec-e6ac-abfd024e19c0@amd.com> (raw)
In-Reply-To: <20190426204327.GM4608@zn.tnic>
On 4/26/19 3:43 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 02:29:31PM +0000, Singh, Brijesh wrote:
>> Yes that's doable but I am afraid that caching the value may lead us to
>> wrong path and also divergence from the SEV API spec. The spec says the
>> returned length is a minimum length but its possible that caller can
>> give a bigger buffer and FW will still work with it.
>
> Does the caller even have a valid reason to give a bigger buffer len?
>
Practically I don't see any reason why caller would do that but
theoretically it can. If we cache the len then we also need to consider
adding another flag to hint whether userspace ever requested length.
e.g an application can compute the length of session blob by looking at
the API version and spec and may never query the length.
> I mean I'm still thinking defensively here but maybe the only thing that
> would happen here with a bigger buffer is if the kmalloc() would fail,
> leading to eventual failure of the migration.
>
> If the code limits the allocation to some sane max length, the migration
> won't fail even if userspace gives it too big values...
>
WARNING: multiple messages have this Message-ID (diff)
From: "Singh, Brijesh" <brijesh.singh@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
"x86@kernel.org" <x86@kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [Qemu-devel] [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command
Date: Mon, 29 Apr 2019 15:01:24 +0000 [thread overview]
Message-ID: <2b63d983-a622-3bec-e6ac-abfd024e19c0@amd.com> (raw)
Message-ID: <20190429150124.9STGQj-xon60PG2pOON30lLlGMpGZwVNi-HPQZHsqSo@z> (raw)
In-Reply-To: <20190426204327.GM4608@zn.tnic>
On 4/26/19 3:43 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 02:29:31PM +0000, Singh, Brijesh wrote:
>> Yes that's doable but I am afraid that caching the value may lead us to
>> wrong path and also divergence from the SEV API spec. The spec says the
>> returned length is a minimum length but its possible that caller can
>> give a bigger buffer and FW will still work with it.
>
> Does the caller even have a valid reason to give a bigger buffer len?
>
Practically I don't see any reason why caller would do that but
theoretically it can. If we cache the len then we also need to consider
adding another flag to hint whether userspace ever requested length.
e.g an application can compute the length of session blob by looking at
the API version and spec and may never query the length.
> I mean I'm still thinking defensively here but maybe the only thing that
> would happen here with a bigger buffer is if the kmalloc() would fail,
> leading to eventual failure of the migration.
>
> If the code limits the allocation to some sane max length, the migration
> won't fail even if userspace gives it too big values...
>
next prev parent reply other threads:[~2019-04-29 15:01 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 16:09 [RFC PATCH v1 00/10] Add AMD SEV guest live migration support Singh, Brijesh
2019-04-24 16:09 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:09 ` Singh, Brijesh
2019-04-24 16:09 ` [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command Singh, Brijesh
2019-04-24 16:09 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:09 ` Singh, Brijesh
2019-04-26 14:10 ` Borislav Petkov
2019-04-26 14:10 ` [Qemu-devel] " Borislav Petkov
2019-04-26 14:10 ` Borislav Petkov
2019-04-26 14:29 ` Singh, Brijesh
2019-04-26 14:29 ` [Qemu-devel] " Singh, Brijesh
2019-04-26 14:29 ` Singh, Brijesh
2019-04-26 20:43 ` Borislav Petkov
2019-04-26 20:43 ` [Qemu-devel] " Borislav Petkov
2019-04-26 20:43 ` Borislav Petkov
2019-04-29 15:01 ` Singh, Brijesh [this message]
2019-04-29 15:01 ` Singh, Brijesh
2019-04-29 15:01 ` Singh, Brijesh
2019-04-29 16:36 ` Borislav Petkov
2019-04-29 16:36 ` [Qemu-devel] " Borislav Petkov
2019-04-29 16:36 ` Borislav Petkov
2019-04-29 16:43 ` Singh, Brijesh
2019-04-29 16:43 ` [Qemu-devel] " Singh, Brijesh
2019-04-29 16:43 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 02/10] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-26 20:31 ` Lendacky, Thomas
2019-04-26 20:31 ` [Qemu-devel] " Lendacky, Thomas
2019-04-26 20:31 ` Lendacky, Thomas
2019-04-29 16:54 ` Singh, Brijesh
2019-04-29 16:54 ` [Qemu-devel] " Singh, Brijesh
2019-04-29 16:54 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 03/10] KVM: SVM: Add KVM_SEV_SEND_FINISH command Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 04/10] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-26 21:08 ` Lendacky, Thomas
2019-04-26 21:08 ` [Qemu-devel] " Lendacky, Thomas
2019-04-26 21:08 ` Lendacky, Thomas
2019-04-24 16:10 ` [RFC PATCH v1 05/10] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-26 21:11 ` Lendacky, Thomas
2019-04-26 21:11 ` [Qemu-devel] " Lendacky, Thomas
2019-04-26 21:11 ` Lendacky, Thomas
2019-04-24 16:10 ` [RFC PATCH v1 06/10] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-26 21:11 ` Lendacky, Thomas
2019-04-26 21:11 ` [Qemu-devel] " Lendacky, Thomas
2019-04-26 21:11 ` Lendacky, Thomas
2019-04-24 16:10 ` [RFC PATCH v1 07/10] KVM: x86: Add AMD SEV specific Hypercall3 Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 08/10] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-26 21:39 ` Lendacky, Thomas
2019-04-26 21:39 ` [Qemu-devel] " Lendacky, Thomas
2019-04-26 21:39 ` Lendacky, Thomas
2019-05-03 14:25 ` Singh, Brijesh
2019-05-03 14:25 ` [Qemu-devel] " Singh, Brijesh
2019-05-03 14:25 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 09/10] KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-24 16:10 ` [RFC PATCH v1 10/10] mm: x86: Invoke hypercall when page encryption status is changed Singh, Brijesh
2019-04-24 16:10 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 16:10 ` Singh, Brijesh
2019-04-24 19:15 ` [RFC PATCH v1 00/10] Add AMD SEV guest live migration support Steve Rutherford
2019-04-24 19:15 ` [Qemu-devel] " Steve Rutherford via Qemu-devel
2019-04-24 19:15 ` Steve Rutherford
2019-04-24 21:32 ` Singh, Brijesh
2019-04-24 21:32 ` [Qemu-devel] " Singh, Brijesh
2019-04-24 21:32 ` Singh, Brijesh
2019-04-25 0:18 ` Steve Rutherford
2019-04-25 0:18 ` Steve Rutherford via Qemu-devel
2019-04-25 2:15 ` Singh, Brijesh
2019-04-25 2:15 ` [Qemu-devel] " Singh, Brijesh
2019-04-25 2:15 ` Singh, Brijesh
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=2b63d983-a622-3bec-e6ac-abfd024e19c0@amd.com \
--to=brijesh.singh@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.