lkml.org 
[lkml]   [2022]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled
    From
    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

    \
     
     \ /
      Last update: 2022-11-22 12:47    [W:4.195 / U:0.920 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site