Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <821e750b-26c9-3331-7577-5cb832a35afa@amd.com>
Date:   Wed, 19 Oct 2022 13:43:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH] virt: Prevent AES-GCM IV reuse in SNP guest driver
Content-Language: en-US
To:     Peter Gonda <pgonda@google.com>
Cc:     Borislav Petkov <bp@suse.de>, Michael Roth <michael.roth@amd.com>,
        Haowen Bai <baihaowen@meizu.com>,
        Yang Yingliang <yangyingliang@huawei.com>,
        Marc Orr <marcorr@google.com>,
        David Rientjes <rientjes@google.com>,
        Ashish Kalra <Ashish.Kalra@amd.com>,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Dionna Glaze <dionnaglaze@google.com>
References: <20221019150333.1047423-1-pgonda@google.com>
 <528937ab-8046-d5d1-26ff-50ef35f5635f@amd.com>
 <CAMkAt6ritG1zmOreh9WYLYAGww0EJQy+m-Y0nfxD5+gpTkpJ1w@mail.gmail.com>
From:   Tom Lendacky <thomas.lendacky@amd.com>
In-Reply-To: <CAMkAt6ritG1zmOreh9WYLYAGww0EJQy+m-Y0nfxD5+gpTkpJ1w@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?TmFGditveEFjQnJEMlhGZnVoUzIvaFp5WGYvei91ZmdiNFlYdm1YOHU0YkFJ?=
 =?utf-8?B?TFNVUTV6ckpHSlNkeWJzZVZQOGNuYlRDRjhqTmVXSitDUE9pUUV2VkdlRGxI?=
 =?utf-8?B?WTE1WW5nRFhIMFFmQWc3cGh5R1AzL0YxaDF4L3FwYmM5WXovRHZNaG1DZVpt?=
 =?utf-8?B?TkNtQmpQN3FXenhHL0ErSzB3eG5GR0N4RlpDNmxnRG1QemVjQ1VlMTRnejhZ?=
 =?utf-8?B?dGtveTZSUUtna1FSTTJlV3g3VkFWK0wzKy9hQlUrVHVpb0gyaC9RakgvdHEx?=
 =?utf-8?B?aWdJNmhMYWEvTSt5WWltL1JONi9DNnZmUTNTdlZZcWl3TGdYbXNzMWVscnYz?=
 =?utf-8?B?aklaNCtRK0QrWWpQVFVndnBKL2k5OWFGOHFOdjZEQmx6dnRXTEhKT3JLV1lH?=
 =?utf-8?B?TjJWTjZSTFllMXI1bkpzcTBvZEhkRVVHQVFjV3BrWVdXbmpBNFFUQkZYOVdj?=
 =?utf-8?B?bWVwZS94bVZJWEk4TkZNVlMrcm9tZW1rTUZkOUFmQnhOR2pxa2NwcXZDNE01?=
 =?utf-8?B?TE5qVWViOHl4a0lhSXpUbnAxdFZyYUF1L1VVNmVJSlE3NGgzbjMwM2thb21r?=
 =?utf-8?B?MU92V3dsc0dvOStLQVIrcnF0cXNwZmlSdUJ2OGFWeWVFNWpFOTAxMDdBN2Fs?=
 =?utf-8?B?YnVxZTN4MkJpTTlwa3ljZ2dCc2thUlc2alM4N24xa3pGRzBkZFVkQytlZXZj?=
 =?utf-8?B?UVY2Z1hpL2FzWVUzOTRJaDIwa2x1WjBlZzhHUGRnUzBWL1dzSy9uZXBid1RJ?=
 =?utf-8?B?TnVnbjA4bDJENDZwcG9LU1R4VzJGMDBJdkdvcjRYbWhnRDZMaWF6Ukh3Q0sv?=
 =?utf-8?B?QTFjZU5LQS83YlI3WEtwMHRmTElYSTdROEdyejh3Qk5jYVdsU1RtRHIvdjIx?=
 =?utf-8?B?SzJVOTZZbERDMTNDNmE1NUdILzM4akMyYzdNVHg0TGFmNUdwRVhDQ2VjbnFt?=
 =?utf-8?B?WGRCYUl0alAvOWVCcURJTUR5eklPWmdvaEp2RWJveTFDZXFXTE85M2p2S2lk?=
 =?utf-8?B?V2NYVGIyOFI0UUF2TDBtd3VESDc5NmJrNTV2QnhXRC9nclVhVkdTWmgzWWFZ?=
 =?utf-8?B?WlJwZHpIME05WnVtSkNEREdJemc2aVIyUlVRRzZkUG15RDFwLzdBV2VvMWto?=
 =?utf-8?B?d0hVQVJBZ3FMejZURnFNRC84N3N6RWtlZ3FLUjlWMWVobE1sMzU3dndldHhH?=
 =?utf-8?B?SXZacm1Ga1QyWlpIM0piSnFlbmZWNndsWUlmMTcyVmg0SGw4MlRqRjUwbjFa?=
 =?utf-8?B?LzNQaXlTblE2OW5IZGNCYVBWVUh3TTlEYTdJOHE5ZU9POGRhMm5FckJ2OWRo?=
 =?utf-8?B?WklDNVFuYXU5YjRxcEUwTnJqWkdxemxhT0JvaGxqeTV1TlFxakVsanVXZno0?=
 =?utf-8?B?TWp2MFZrWXlIMEY2TjBybXJhSkJmVitCdkVLeW53YXRHYjNRanh6cExrY3B4?=
 =?utf-8?B?YUdEcWd3dFhCait2ekpQT2RRVDcxeXRleEpIWXdZOWNZZVV5dGhhNE1NT2NH?=
 =?utf-8?B?V2RDQ3NuN1ZNZUJBUThjWGVvV2FobDJBanRzRDRvUW1ReERZdHMyS29od1Ru?=
 =?utf-8?B?Z0JLaHhtTXg2dkdHb3Q2MjdFSTloRDdLTnVES0dQa254TEVtVG9oRGU0clRB?=
 =?utf-8?B?dHNLTUNGU2t5cWNHeUpaeWpBMWVkZG03SFd4RnlsWDZjWnprQ2pTMWFCQnNL?=
 =?utf-8?B?SEp5bWZyM0lnb1h4Wm9hTmFwUTBSQ29aYVU2d1VpcVNCQ2dhTmF4YThVamZ3?=
 =?utf-8?B?bS81M3VkSXdHTG0yK01wUHk0UjA0ZnFtMVZXSmFTb2hqS3VTOE1uU1BvRzRF?=
 =?utf-8?B?U2Z1a1FVQ2phK1ljaElvaWpjUkxKZWZqUjJ5ODRQWW1kSjZBQk42Sno5a0hQ?=
 =?utf-8?B?M0pnZ1phZ2FDL0FKNWxOTkNReklnNjZtV1VEaUFlY1AzQ081dzBaWXBSSTdl?=
 =?utf-8?B?ZHQ2cDBwY2RLczljaDdpblcyS1pqV2o3dkdndkNNYmp5Rkx3ZWw2ZVlmM2pr?=
 =?utf-8?B?Z1BmUUVKOVFxbDR1Qm1xc1l5aWhyVVdaZlpDQmMzQ040eDBLbjBEUHJTdUlU?=
 =?utf-8?B?TTdoc0hVWDR0RW5CWHk3Q2I3YTZzajl3RXJkd2lRMWpMbDBTdW84UDcyV053?=
 =?utf-8?Q?0ok6Ug8cH8k2MhPX90wAbw2ok?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a128f351-ffca-4995-72d4-08dab201e3ba
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5229.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2022 18:44:01.2954
 (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: cvYiHVgn2Yg+smteGiwswV7b0M/602kMDew67lEWVuSRpfJdrLPobp4BlQVWUfKEGgmR0DYWY3pVJbUcSH1y8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4151
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/19/22 12:40, Peter Gonda wrote:
> On Wed, Oct 19, 2022 at 11:03 AM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> On 10/19/22 10:03, Peter Gonda wrote:
>>> The ASP and an SNP guest use a series of AES-GCM keys called VMPCKs to
>>> communicate securely with each other. The IV to this scheme is a
>>> sequence number that both the ASP and the guest track. Currently this
>>> sequence number in a guest request must exactly match the sequence
>>> number tracked by the ASP. This means that if the guest sees an error
>>> from the host during a request it can only retry that exact request or
>>> disable the VMPCK to prevent an IV reuse. AES-GCM cannot tolerate IV
>>> reuse see:
>>> https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf
>>

I think I've wrapped my head around this now. Any non-zero return code 
from the hypervisor for an SNP Guest Request is either a hypervisor error 
or an sev-guest driver error, and so the VMPCK should be disabled. The 
sev-guest driver is really doing everything (message headers, performing 
the encryption, etc.) and is only using userspace data that will be part 
of the response message and can't result in a non-zero hypervisor return code.

For the SNP Extended Guest Request, we only need to special case a return 
code of SNP_GUEST_REQ_INVALID_LEN. See below for my responses on that.


>> I wonder if we can at least still support the extended report length query
>> by having the kernel allocate the required pages when the error is
>> SNP_GUEST_REQ_INVALID_LEN and retry the exact request again. If there are
>> no errors on the second request, the sequence numbers can be safely
>> updated, but the kernel returns the original error (which will provide the
>> caller with the number of pages required).
> 
> I think we can but I thought fixing the security bug could come first,
> then the usability fix after. Dionna was planning on working on that
> fix.
> 
> In that flow how does userspace get the data? Its called the ioctl
> with not enough output buffer space. What if the userspace calls the
> ioctl with no buffers space allocated, so its trying to query the
> length. We just send the host the request without any encrypted data.

In the case of SNP_GUEST_REQ_INVALID_LEN, userspace wouldn't get the data 
if it hasn't supplied enough buffer space. But, the sev-guest driver can 
supply enough buffer space and invoke the SNP Extended Guest Request again 
in order to successfully complete the call and update the sequence 
numbers. The sev-guest driver would just discard the data in this case, 
but pass back the original "not enough buffer space" error to the caller, 
who could now allocate space and retry. This then allows the sequence 
numbers to be bumped properly.

> 
>>
>> For the rate-limiting patch series [1], the rate-limiting will have to be
>> performed within the kernel, while the mutex is held, and then retry the
>> exact request again. Otherwise, that error will require disabling the
>> VMPCK. Either that, or the hypervisor must provide the rate limiting.
>>
>> Thoughts?
>>
>> [1] https://lore.kernel.org/lkml/20221013160040.2858732-1-dionnaglaze@google.com/
> 
> Yes I think if the host rate limits the guest. The guest kernel should
> retry the exact message. Which mutex are you referring too?

Or the host waits and then submits the request and the guest kernel 
doesn't have to do anything. The mutex I'm referring to is the 
snp_cmd_mutex that is taken in snp_guest_ioctl().

Thanks,
Tom