diff mbox

[Part2,v6,16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command

Message ID 20171020023413.122280-17-brijesh.singh@amd.com (mailing list archive)
State New, archived
Headers show

Commit Message

Brijesh Singh Oct. 20, 2017, 2:33 a.m. UTC
The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Gary Hook <gary.hook@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-crypto@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 drivers/crypto/ccp/psp-dev.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Borislav Petkov Oct. 23, 2017, 9:32 a.m. UTC | #1
On Thu, Oct 19, 2017 at 09:33:51PM -0500, Brijesh Singh wrote:
> The SEV_PEK_GEN command is used to generate a new Platform Endorsement
> Key (PEK). The command is defined in SEV spec section 5.6.
> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Gary Hook <gary.hook@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: linux-crypto@vger.kernel.org
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 5c921b36bc23..1d7212da25a5 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -195,6 +195,24 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
>  	return ret;
>  }
>  
> +static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
> +{
> +	int ret, err;
> +
> +	ret = sev_platform_init(NULL, &argp->error);
> +	if (ret)
> +		return ret;
> +
> +	ret = sev_do_cmd(cmd, 0, &argp->error);

So this ret value gets potentially overwritten here. You need
to either handle the case properly when sev_do_cmd() fails and
sev_platform_shutdown() gets to issue SEV_CMD_SHUTDOWN (i.e., when it
gets overwritten), or not write into ret at all by initializing it to 0
at function entry.
Brijesh Singh Oct. 23, 2017, 12:15 p.m. UTC | #2
On 10/23/17 4:32 AM, Borislav Petkov wrote:
...
>> +static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
>> +{
>> +	int ret, err;
>> +
>> +	ret = sev_platform_init(NULL, &argp->error);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = sev_do_cmd(cmd, 0, &argp->error);
> So this ret value gets potentially overwritten here. You need
> to either handle the case properly when sev_do_cmd() fails and
> sev_platform_shutdown() gets to issue SEV_CMD_SHUTDOWN (i.e., when it
> gets overwritten), or not write into ret at all by initializing it to 0
> at function entry.
>

I am not sure if I am able to understand your feedback. The
sev_platform_shutdown() is called unconditionally.

1) if sev_do_cmd() fails and sev_platform_shutdown() was success then
'ret' will contain the  error code from sev_do_cmd().
2) if sev_do_cmd() was success but sev_platform_shutdown() fails then
'ret' will contain the error code from sev_platform_shutdown()
3) if both sev_do_cmd() and sev_platform_shutdown() fails then 'ret'
will contain error code from the sev_platform_shutdown().
Borislav Petkov Oct. 23, 2017, 12:32 p.m. UTC | #3
On Mon, Oct 23, 2017 at 07:15:30AM -0500, Brijesh Singh wrote:
> I am not sure if I am able to understand your feedback. The
> sev_platform_shutdown() is called unconditionally.

How's that:

If sev_do_cmd() fails and sev_do_cmd(SEV_CMD_SHUTDOWN, ...) in
sev_platform_shutdown() fails, then the first ret from sev_do_cmd() is
gone.
Brijesh Singh Oct. 23, 2017, 1:32 p.m. UTC | #4
On 10/23/17 7:32 AM, Borislav Petkov wrote:
> On Mon, Oct 23, 2017 at 07:15:30AM -0500, Brijesh Singh wrote:
>> I am not sure if I am able to understand your feedback. The
>> sev_platform_shutdown() is called unconditionally.
> How's that:
>
> If sev_do_cmd() fails and sev_do_cmd(SEV_CMD_SHUTDOWN, ...) in
> sev_platform_shutdown() fails, then the first ret from sev_do_cmd() is
> gone.

If both the command fails then we return status from the last command.
IIRC, in my previous patches I was returning status from sev_do_cmd()
instead of sev_platform_shutdown() but based on our previous
communication I thought you asked to return the status from the last
failed command. Did I miss understood ?

-Brijesh
Borislav Petkov Oct. 23, 2017, 2:10 p.m. UTC | #5
On Mon, Oct 23, 2017 at 08:32:57AM -0500, Brijesh Singh wrote:
> If both the command fails then we return status from the last command.
> IIRC, in my previous patches I was returning status from sev_do_cmd()
> instead of sev_platform_shutdown() but based on our previous
> communication I thought you asked to return the status from the last
> failed command. Did I miss understood ?

So my problem is that it looks strange that you save an error value from
sev_do_cmd() but you don't look at it. And as I said in the other mail,
you should either ignore it and say so in a comment why it is OK to
ignore it or handle it but not overwrite it without looking at it.

Does that make more sense?
Brijesh Singh Oct. 23, 2017, 8 p.m. UTC | #6
On 10/23/2017 09:10 AM, Borislav Petkov wrote:
> On Mon, Oct 23, 2017 at 08:32:57AM -0500, Brijesh Singh wrote:
>> If both the command fails then we return status from the last command.
>> IIRC, in my previous patches I was returning status from sev_do_cmd()
>> instead of sev_platform_shutdown() but based on our previous
>> communication I thought you asked to return the status from the last
>> failed command. Did I miss understood ?
> 
> So my problem is that it looks strange that you save an error value from
> sev_do_cmd() but you don't look at it. And as I said in the other mail,
> you should either ignore it and say so in a comment why it is OK to
> ignore it or handle it but not overwrite it without looking at it.
> 
> Does that make more sense?
> 

I see your point, if both commands failed then I am now inclined towards 
ignoring the error code from shutdown command and add some comments 
explaining why its OK. thanks

-Brijesh
diff mbox

Patch

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 5c921b36bc23..1d7212da25a5 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -195,6 +195,24 @@  static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
 	return ret;
 }
 
+static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp)
+{
+	int ret, err;
+
+	ret = sev_platform_init(NULL, &argp->error);
+	if (ret)
+		return ret;
+
+	ret = sev_do_cmd(cmd, 0, &argp->error);
+
+	if (sev_platform_shutdown(&err)) {
+		argp->error = err;
+		ret = -EIO;
+	}
+
+	return ret;
+}
+
 static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 {
 	void __user *argp = (void __user *)arg;
@@ -218,6 +236,9 @@  static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg)
 	case SEV_PLATFORM_STATUS:
 		ret = sev_ioctl_do_platform_status(&input);
 		break;
+	case SEV_PEK_GEN:
+		ret = sev_ioctl_do_pek_pdh_gen(SEV_CMD_PEK_GEN, &input);
+		break;
 	default:
 		ret = -EINVAL;
 		goto out;