Message-ID: <0c3a11bb-9036-2067-bf73-d18bb55c1225@amd.com>
Date:   Thu, 23 Feb 2023 10:14:37 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [RESEND PATCH] virt/sev-guest: Return -EIO if certificate buffer
 is not large enough
Content-Language: en-US
To:     Peter Gonda <pgonda@google.com>
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org,
        Borislav Petkov <bp@alien8.de>,
        Larry Dewey <larry.dewey@amd.com>
References: <2afbcae6daf13f7ad5a4296692e0a0fe1bc1e4ee.1677083979.git.thomas.lendacky@amd.com>
 <CAMkAt6pqyOqVd_etLVfwrihEoc6XtS+BaVsV8x934rr4LmOCgw@mail.gmail.com>
From:   Tom Lendacky <thomas.lendacky@amd.com>
In-Reply-To: <CAMkAt6pqyOqVd_etLVfwrihEoc6XtS+BaVsV8x934rr4LmOCgw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1BBWVlNZHBwNGQwRW1oeEUxbU9ScHJnVEhuTkVXTzJrcFFZU21ReDI4OHBL?=
 =?utf-8?B?Q2h6YVdCankwQTFtcGJDQllDL216VE05TEV5b2NGVmNtVU5EUFgwTVVwcysz?=
 =?utf-8?B?dWVrTllhWUpYNWxPdmZlaC81cy9yQUpsaDlLMVFUWWhDdjFDbEZXMzFjQU52?=
 =?utf-8?B?cFJYQ2IxL0xPSkkwaXBGcWcrZnhqOFJKRUF2QXV6clVFMi9WOXhhY1E3NXp1?=
 =?utf-8?B?L0k2cUMwa0NMaGhGbjNEKzdtU01ndWhZSzgvZlRsR3NSL3JEVFJSMEV5bVVm?=
 =?utf-8?B?am9PV1dpVTVacTRnR05DUGIzQ3NrMGg0TGFwZlI4N21aeFE0YkpPbzMvazI0?=
 =?utf-8?B?TjF1eDdYWnp4clluNENqTVp0QzNlUGNraWxwa1Rxdm84KzBuTTRGOHIwS1Jo?=
 =?utf-8?B?MTFHclo3Qm13TGZMN3lQSlg2MUNSN1Y5bjJjZW9OTHRHQytLNWozdjF6N2Vj?=
 =?utf-8?B?akg4Ky9JYWtzU0NtRlNRK2xaRVhSMmg0MUQxTVpSdkJMblZGVjY2bXZMQm5P?=
 =?utf-8?B?bWNVTTUydmlnSzlhYUtFUis4TzQ1RzEwdUJXTXdpaGRGWHRHc1VWMitRcTNp?=
 =?utf-8?B?amlIQS9IZ280b1ZOeW8xalI5MjVIYU5pK2o3T0RsWGlyemZxci9kbUM3bkpy?=
 =?utf-8?B?SnFMRUJqY1Q4MUFhQWpGcUxNUjFTcXBuamp0NWhnVWYvRm9sUi9zcVYzZU1J?=
 =?utf-8?B?L2JxRi9qVFAvRUNzZmN2a1lVZllpdWRqTnBFQytnSUlpZm8vUW5QTVdsb2xE?=
 =?utf-8?B?Vm00RzVvcjZsaFJ2TGMreHVwWVJLZDFFc3RLOERzaDZRai9maDN4U0RYTU12?=
 =?utf-8?B?TSsyQmN6STFQRjl6Zld6blo1TngrNXdwekJxcjMyOUtBd2dId0xPTjFjaUVj?=
 =?utf-8?B?Y2h6cUFaTE9sRnRpWkFuZE1IM29JYU5iVVRHNm4zU2hRbXFhKzdtODV5STc2?=
 =?utf-8?B?WUc0Yko3L29PVnB5cUNiNDBzNiszZEhUUDhjVzY5L0VMRUFUcVdTb2hsTUg5?=
 =?utf-8?B?alFSL21LOWZYM1dDY0E2OExubUdRc29wZkdJUGVaMnYvWVh3Q3c3NWJwem05?=
 =?utf-8?B?bFZ1RDF3T3o1eEtWZHhqcnZQbXMwdE16TUJYSy93WTc4N3BLYWFwOHdoSkl0?=
 =?utf-8?B?TTJEQVBJc3ZnT2FtRTNnNXYrYVBlSFJzcmNRc2RMMjhjdTRiVHkxM3BHZk0x?=
 =?utf-8?B?MG1pQzRKWFBkdXByeUlHUXdadGswaXcrYzdnK05oUU45UXRNbjRXcFUyQmtK?=
 =?utf-8?B?ZnJRSGN2Ly9uRitLQzVyQ3J0Wms1SU1QeE0zRWIxSVJnSnFtTTNrdUNkTmJB?=
 =?utf-8?B?YkQzVFc0TFJaaGJ6RXFwTjY2M3dFN3M2eEZtMlJraFQzNm44Q1pKTVFIZzQ3?=
 =?utf-8?B?d3N6Z2ZHLzlud3M3bDRnZWJZT2JpVXp1MitQYWZaaW5jdmJMWHpjSHRkS0Zo?=
 =?utf-8?B?alFjbG01U0FVWTNXandGRVdiWXZVUmhvQTREaVdvMjNuM1RoMnNaMktGOC9w?=
 =?utf-8?B?S0NBTWRFaDl2NVZndTRiKzIyVUpTbE1BOHRUbklzcWZCWUFvMmpRcGJxZU1R?=
 =?utf-8?B?Vzl3azdUNEoxN2NETUQyTnBDVTJKblgzaENzRVFieGNkS2QxclY3dHdBTlJM?=
 =?utf-8?B?MStHclVpSnF1eDJnZ3lJS1NobnN3dW1mMHNxUjNaRWI3b2J1Zko5SCtHVWFz?=
 =?utf-8?B?YXBUMm9XbUk5am5DcyswM3JKNWdpZC9MVjhGYnY3Q3QyMWNRWnFucWZIUk4z?=
 =?utf-8?B?OVEyQyttaUQwR25NMXhiYzhtbFlmMVJFWXBiRGJWMkxWZjJvcDllZEVzZmhG?=
 =?utf-8?B?U0Z2OVhQbTk2OE5lMFkvN2FjSUJoMUlxcDlVZVZhdEIwSjVBY2Y2YXNNOEFD?=
 =?utf-8?B?ZDdnSlBFRTRTN3FwVDYzMmEwNWk5WnZyTXUrcExBaW0xbGxaUGlkQ05iRTBp?=
 =?utf-8?B?d3o3UzVuNkJmVkdEK0RmMjd2RlpDSWxkSkw3RFJtdVBrWVdLNCtqeVZrT1JD?=
 =?utf-8?B?Vm1MZm0xakdDWGNFNmpBb3hvc2t1U2xPTlY5M2F2NDd6OTFZUk5kbFIrTjhu?=
 =?utf-8?B?SFlaV1Q5WHNPMlQrMXFWamFJcmp1aE9LR0xuYTZIOHAvSCsrVjJkUkFPSTFL?=
 =?utf-8?Q?PQ6npoTgfckdBRk/PqD+P3AhP?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d4fe3a92-913b-4c6d-48b8-08db15b91128
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 16:14:40.5917
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: GVO++Te7kCAXy0maQNeVpPrGm0SVBsMeLIdWfW3QDWM5mhyVwrz2gbFXjzfZu2db44vDrht9yd4rDdPgAQinhA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5403
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/22/23 10:51, Peter Gonda wrote:
> On Wed, Feb 22, 2023 at 9:39 AM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> Commit 47894e0fa6a5 ("virt/sev-guest: Prevent IV reuse in the SNP guest
>> driver") changed the behavior associated with the return value when the
>> caller does not supply a large enough certificate buffer. Prior to the
>> commit a return value of -EIO was returned. Now a return value of 0 is
>> returned. This breaks the established ABI with the user.
>>
>> Change the code to detect the buffer size error and return -EIO.
>>
>> Fixes: 47894e0fa6a5 ("virt/sev-guest: Prevent IV reuse in the SNP guest driver")
>> Reported-by: Larry Dewey <larry.dewey@amd.com>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> 
> My bad. I wasn't testing the return value in this case.
> 
> Should Boris take this patch into the retry series?
> 
>> ---
>>   drivers/virt/coco/sev-guest/sev-guest.c | 20 +++++++++++++++++---
>>   1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
>> index 4ec4174e05a3..7b4e9009f335 100644
>> --- a/drivers/virt/coco/sev-guest/sev-guest.c
>> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
>> @@ -377,9 +377,26 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>>                  snp_dev->input.data_npages = certs_npages;
>>          }
>>
>> +       /*
>> +        * Increment the message sequence number. There is no harm in doing
>> +        * this now because decryption uses the value stored in the response
>> +        * structure and any failure will wipe the VMPCK, preventing further
>> +        * use anyway.
>> +        */
>> +       snp_inc_msg_seqno(snp_dev);
>> +
>>          if (fw_err)
>>                  *fw_err = err;
>>
>> +       /*
>> +        * If an extended guest request was issued and the supplied certificate
>> +        * buffer was not large enough, a standard guest request was issued to
>> +        * prevent IV reuse. If the standard request was successful, return -EIO
>> +        * back to the caller as would have originally been returned.
>> +        */
>> +       if (!rc && err == SNP_GUEST_REQ_INVALID_LEN)
>> +               return -EIO;
>> +
> 
> Why not set 'ret = -EIO' and use disable_vmpck directly? That seems
> more clear to me instead of failing on the next call.

We don't want to disable the VMPCK for this. This should go back to 
userspace with EIO and SNP_GUEST_REQ_INVALID_LEN, as it did prior to 
47894e0fa6a5. Userspace then allocates a larger buffer and re-issues the 
request which should now succeed.

Thanks,
Tom

> 
>>          if (rc) {
>>                  dev_alert(snp_dev->dev,
>>                            "Detected error from ASP request. rc: %d, fw_err: %llu\n",
>> @@ -395,9 +412,6 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>>                  goto disable_vmpck;
>>          }
>>
>> -       /* Increment to new message sequence after payload decryption was successful. */
>> -       snp_inc_msg_seqno(snp_dev);
>> -
>>          return 0;
>>
>>   disable_vmpck:
>> --
>> 2.39.1
>>