<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in sev-dev.h</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>a867ad6b - crypto: ccp: Handle legacy SEV commands when SNP is enabled</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#a867ad6b</link>
        <description>crypto: ccp: Handle legacy SEV commands when SNP is enabledThe behavior of legacy SEV commands is altered when the firmware isinitialized for SNP support. In that case, all command buffer memorythat may get written to by legacy SEV commands must be marked asfirmware-owned in the RMP table prior to issuing the command.Additionally, when a command buffer contains a system physical addressthat points to additional buffers that firmware may write to, specialhandling is needed depending on whether:  1) the system physical address points to guest memory  2) the system physical address points to host memoryTo handle case #1, the pages of these buffers are changed tofirmware-owned in the RMP table before issuing the command, and restoredto hypervisor-owned after the command completes.For case #2, a bounce buffer is used instead of the original address.Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Co-developed-by: Michael Roth &lt;michael.roth@amd.com&gt;Signed-off-by: Michael Roth &lt;michael.roth@amd.com&gt;Signed-off-by: Ashish Kalra &lt;ashish.kalra@amd.com&gt;Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;Link: https://lore.kernel.org/r/20240126041126.1927228-19-michael.roth@amd.com

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Fri, 26 Jan 2024 04:11:18 +0000</pubDate>
        <dc:creator>Brijesh Singh &lt;brijesh.singh@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>1ca5614b - crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#1ca5614b</link>
        <description>crypto: ccp: Add support to initialize the AMD-SP for SEV-SNPBefore SNP VMs can be launched, the platform must be appropriatelyconfigured and initialized via the SNP_INIT command.During the execution of SNP_INIT command, the firmware configuresand enables SNP security policy enforcement in many system components.Some system components write to regions of memory reserved by earlyx86 firmware (e.g. UEFI). Other system components write to regionsprovided by the operation system, hypervisor, or x86 firmware.Such system components can only write to HV-fixed pages or Defaultpages. They will error when attempting to write to pages in other pagestates after SNP_INIT enables their SNP enforcement.Starting in SNP firmware v1.52, the SNP_INIT_EX command takes a list ofsystem physical address ranges to convert into the HV-fixed page statesduring the RMP initialization. If INIT_RMP is 1, hypervisors shouldprovide all system physical address ranges that the hypervisor willnever assign to a guest until the next RMP re-initialization.For instance, the memory that UEFI reserves should be included in therange list. This allows system components that occasionally write tomemory (e.g. logging to UEFI reserved regions) to not fail due toRMP initialization and SNP enablement.Note that SNP_INIT(_EX) must not be executed while non-SEV guests areexecuting, otherwise it is possible that the system could reset or hang.The psp_init_on_probe module parameter was added for SEV/SEV-ES supportand the init_ex_path module parameter to allow for time for thenecessary file system to be mounted/available.SNP_INIT(_EX) does not use the file associated with init_ex_path. So, toavoid running into issues where SNP_INIT(_EX) is called while there areother running guests, issue it during module probe regardless of thepsp_init_on_probe setting, but maintain the previous deferrable handlingfor SEV/SEV-ES initialization.  [ mdr: Squash in psp_init_on_probe changes from Tom, reduce    proliferation of &apos;probe&apos; function parameter where possible.    bp: Fix 32-bit allmodconfig build. ]Signed-off-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Co-developed-by: Ashish Kalra &lt;ashish.kalra@amd.com&gt;Signed-off-by: Ashish Kalra &lt;ashish.kalra@amd.com&gt;Co-developed-by: Jarkko Sakkinen &lt;jarkko@profian.com&gt;Signed-off-by: Jarkko Sakkinen &lt;jarkko@profian.com&gt;Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Signed-off-by: Michael Roth &lt;michael.roth@amd.com&gt;Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;Link: https://lore.kernel.org/r/20240126041126.1927228-14-michael.roth@amd.com

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Fri, 26 Jan 2024 04:11:13 +0000</pubDate>
        <dc:creator>Brijesh Singh &lt;brijesh.singh@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>1c5c1daf - crypto: ccp - Move some PSP mailbox bit definitions into common header</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#1c5c1daf</link>
        <description>crypto: ccp - Move some PSP mailbox bit definitions into common headerSome of the bits and fields used for mailboxes communicating with thePSP are common across all mailbox implementations (SEV, TEE, etc).Move these bits into the common `linux/psp.h` so they don&apos;t need tobe re-defined for each implementation.Acked-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Fri, 10 Mar 2023 21:19:46 +0000</pubDate>
        <dc:creator>Mario Limonciello &lt;mario.limonciello@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>a402e351 - crypto: ccp: Use the stack and common buffer for INIT command</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#a402e351</link>
        <description>crypto: ccp: Use the stack and common buffer for INIT commandDrop the dedicated init_cmd_buf and instead use a local variable.  Nowthat the low level helper uses an internal buffer for all commands,using the stack for the upper layers is safe even when running withCONFIG_VMAP_STACK=y.Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;Message-Id: &lt;20210406224952.4177376-8-seanjc@google.com&gt;Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Tue, 06 Apr 2021 22:49:51 +0000</pubDate>
        <dc:creator>Sean Christopherson &lt;seanjc@google.com&gt;</dc:creator>
    </item>
<item>
        <title>38103671 - crypto: ccp: Use the stack and common buffer for status commands</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#38103671</link>
        <description>crypto: ccp: Use the stack and common buffer for status commandsDrop the dedicated status_cmd_buf and instead use a local variable forPLATFORM_STATUS.  Now that the low level helper uses an internal bufferfor all commands, using the stack for the upper layers is safe even whenrunning with CONFIG_VMAP_STACK=y.Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;Message-Id: &lt;20210406224952.4177376-7-seanjc@google.com&gt;Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Tue, 06 Apr 2021 22:49:50 +0000</pubDate>
        <dc:creator>Sean Christopherson &lt;seanjc@google.com&gt;</dc:creator>
    </item>
<item>
        <title>8347b994 - crypto: ccp: Play nice with vmalloc&apos;d memory for SEV command structs</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#8347b994</link>
        <description>crypto: ccp: Play nice with vmalloc&apos;d memory for SEV command structsCopy the incoming @data comman to an internal buffer so that callers canput SEV command buffers on the stack without running afoul ofCONFIG_VMAP_STACK=y, i.e. without bombing on vmalloc&apos;d pointers.  As oftoday, the largest supported command takes a 68 byte buffer, i.e. prettymuch every command can be put on the stack.  Because sev_cmd_mutex isheld for the entirety of a transaction, only a single bounce buffer isrequired.Use the internal buffer unconditionally, as the majority of in-kernelusers will soon switch to using the stack.  At that point, checkingvirt_addr_valid() becomes (negligible) overhead in most cases, andsupporting both paths slightly increases complexity.  Since the commandsare all quite small, the cost of the copies is insignificant compared tothe latency of communicating with the PSP.Allocate a full page for the buffer as opportunistic preparation forSEV-SNP, which requires the command buffer to be in firmware state forcommands that trigger memory writes from the PSP firmware.  Using a fullpage now will allow SEV-SNP support to simply transition the page asneeded.Cc: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Cc: Borislav Petkov &lt;bp@suse.de&gt;Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Cc: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;Message-Id: &lt;20210406224952.4177376-5-seanjc@google.com&gt;Reviewed-by: Brijesh Singh &lt;brijesh.singh@amd.com&gt;Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Tue, 06 Apr 2021 22:49:48 +0000</pubDate>
        <dc:creator>Sean Christopherson &lt;seanjc@google.com&gt;</dc:creator>
    </item>
<item>
        <title>6eb0cc72 - crypto: ccp - move SEV vdata to a dedicated data structure</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#6eb0cc72</link>
        <description>crypto: ccp - move SEV vdata to a dedicated data structurePSP can support both SEV and TEE interface. Therefore, moveSEV specific registers to a dedicated data structure.TEE interface specific registers will be added in a laterpatch.Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;Co-developed-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Wed, 04 Dec 2019 06:19:00 +0000</pubDate>
        <dc:creator>Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>b93566f1 - crypto: ccp - create a generic psp-dev file</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#b93566f1</link>
        <description>crypto: ccp - create a generic psp-dev fileThe PSP (Platform Security Processor) provides support for key managementcommands in Secure Encrypted Virtualization (SEV) mode, along withsoftware-based Trusted Execution Environment (TEE) to enable third-partyTrusted Applications.Therefore, introduce psp-dev.c and psp-dev.h files, which can invokeSEV (or TEE) initialization based on platform feature support.TEE interface support will be introduced in a later patch.Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;Co-developed-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Wed, 04 Dec 2019 06:18:59 +0000</pubDate>
        <dc:creator>Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>9b67d08d - crypto: ccp - rename psp-dev files to sev-dev</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/crypto/ccp/sev-dev.h#9b67d08d</link>
        <description>crypto: ccp - rename psp-dev files to sev-devThis is a preliminary patch for creating a generic PSP device driverfile, which will have support for both SEV and TEE (Trusted ExecutionEnvironment) interface.This patch does not introduce any new functionality, but simply renamespsp-dev.c and psp-dev.h files to sev-dev.c and sev-dev.h filesrespectively.Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;Co-developed-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Devaraj Rangasamy &lt;Devaraj.Rangasamy@amd.com&gt;Signed-off-by: Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

            List of files:
            /linux-6.15/drivers/crypto/ccp/sev-dev.h</description>
        <pubDate>Wed, 04 Dec 2019 06:18:58 +0000</pubDate>
        <dc:creator>Rijo Thomas &lt;Rijo-john.Thomas@amd.com&gt;</dc:creator>
    </item>
</channel>
</rss>
