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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux