On Wed, Sep 13, 2017 at 01:58:31PM -0500, Brijesh Singh wrote:
> Actually reversed fields are not exposed in userspace structure.
Ok.
> The current approach is -- while handling the command we copy the value
> from userspace structure into FW compatible structure and also populate
> missing
On Wed, Sep 13, 2017 at 01:58:31PM -0500, Brijesh Singh wrote:
> Actually reversed fields are not exposed in userspace structure.
Ok.
> The current approach is -- while handling the command we copy the value
> from userspace structure into FW compatible structure and also populate
> missing
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
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
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
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
On 09/13/2017 12:25 PM, Borislav Petkov wrote:
...
+static void sev_deactivate_handle(struct kvm *kvm, int *error);
+static void sev_decommission_handle(struct kvm *kvm, int *error);
Please move code in a way that you don't need those forward
declarations. Also, I'm wondering if having all
On 09/13/2017 12:25 PM, Borislav Petkov wrote:
...
+static void sev_deactivate_handle(struct kvm *kvm, int *error);
+static void sev_decommission_handle(struct kvm *kvm, int *error);
Please move code in a way that you don't need those forward
declarations. Also, I'm wondering if having all
On Mon, Jul 24, 2017 at 03:02:52PM -0500, Brijesh Singh wrote:
> The command is used to bootstrap SEV guest from unencrypted boot images.
> The command creates a new VM encryption key (VEK) using the guest owner's
s/The command/It/
> policy, public DH certificates, and session information.
>
>
On Mon, Jul 24, 2017 at 03:02:52PM -0500, Brijesh Singh wrote:
> The command is used to bootstrap SEV guest from unencrypted boot images.
> The command creates a new VM encryption key (VEK) using the guest owner's
s/The command/It/
> policy, public DH certificates, and session information.
>
>
The command is used to bootstrap SEV guest from unencrypted boot images.
The command creates a new VM encryption key (VEK) using the guest owner's
policy, public DH certificates, and session information.
Signed-off-by: Brijesh Singh
---
arch/x86/kvm/svm.c | 165
The command is used to bootstrap SEV guest from unencrypted boot images.
The command creates a new VM encryption key (VEK) using the guest owner's
policy, public DH certificates, and session information.
Signed-off-by: Brijesh Singh
---
arch/x86/kvm/svm.c | 165
12 matches
Mail list logo