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

Kalra, Ashish
2022-11-22T11:44:59Z

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