Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled

[Kalra, Ashish]

On 11/22/2022 4:44 AM, Borislav Petkov wrote:
> On Tue, Nov 22, 2022 at 04:32:18AM -0600, Kalra, Ashish wrote:
> > Please note that in both cases, these non-reclaimed pages cannot be
> > freed/returned back to the page allocator.
>
> You keep repeating "these pages". Which pages?

The pages which have been allocated for firmware use (such as for 
SNP_INIT command, TMR memory for SEV-ES usage, etc), command buffers 
used for SEV legacy commands when SNP is enabled.

Here is a detailed description of the SEV legacy command handling when 
SNP is enabled:
The behavior of the SEV-legacy commands is altered when the SNP firmware
is in the INIT state. When SNP is in INIT state, all the SEV-legacy
commands that cause the firmware to write to memory must be in the
firmware state before issuing the command. A command buffer may contain 
a system physical address that the firmware may write to. In case the 
command buffer contains a system physical address points to a guest 
memory, we need to change the page state to the firmware in the RMP
table before issuing the command and restore the state to shared after 
the command completes.

Then there are host buffers allocated for SNP platform status command, 
SNP launch update and SNP launch update vmsa command.

The other pages which can be user or guest provided are SNP guest 
requests and SNP guest debug helpers.

It is important to note that if invalid address/len are supplied, the 
failure will happen at the initial stage itself of transitioning these 
pages to firmware state.

But if the above pages have been successfully transitioned to firmware 
state and passed on to the SNP firmware, then after return, they need to 
be restored to shared state. If this restoration/reclamation fails, then 
accessing these pages will cause the kernel to panic.

> What if you specify the wrong, innocent pages because the kernel is
> wrong?

In such a case the kernel panic is justifiable, but again if incorrect 
addresses are supplied, the failure will happen at the initial stage of 
transitioning these pages to firmware state and there is no need to 
reclaim.

Or, otherwise dump a warning and let the pages not be freed/returned 
back to the page allocator.

It is either innocent pages or kernel panic or an innocent host process 
crash (these are the choices to make).

Thanks,
Ashish