Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4 |
|
#
c04cf9e1 |
| 23-Jun-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - Add support for fetching a nonce for dynamic boost control
Dynamic Boost Control is a feature offered on AMD client platforms that allows software to request and set power or frequency
crypto: ccp - Add support for fetching a nonce for dynamic boost control
Dynamic Boost Control is a feature offered on AMD client platforms that allows software to request and set power or frequency limits.
Only software that has authenticated with the PSP can retrieve or set these limits.
Create a character device and ioctl for fetching the nonce. This ioctl supports optionally passing authentication information which will influence how many calls the nonce is valid for.
Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
b8440d55 |
| 23-Jun-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - move setting PSP master to earlier in the init
Dynamic boost control needs to use platform access symbols that look for the PSP master as part of initialization.
So move the PSP maste
crypto: ccp - move setting PSP master to earlier in the init
Dynamic boost control needs to use platform access symbols that look for the PSP master as part of initialization.
So move the PSP master before psp_init() so that dynamic boost control can be initialized properly.
Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22 |
|
#
45121ad4 |
| 28-Mar-2023 |
Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> |
crypto: ccp - Clear PSP interrupt status register before calling handler
The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by the psp module so clear the interrupt status register
crypto: ccp - Clear PSP interrupt status register before calling handler
The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by the psp module so clear the interrupt status register early in the handler to prevent missed interrupts. sev_irq_handler() calls wake_up() on a wait queue, which can result in a new command being submitted from a different CPU. This then races with the clearing of isr and can result in missed interrupts. A missed interrupt results in a command waiting until it times out, which results in the psp being declared dead.
This is unlikely on bare metal, but has been observed when running virtualized. In the cases where this is observed, sev->cmdresp_reg has PSP_CMDRESP_RESP set which indicates that the command was processed correctly but no interrupt was asserted.
The full sequence of events looks like this:
CPU 1: submits SEV cmd #1 CPU 1: calls wait_event_timeout() CPU 0: enters psp_irq_handler() CPU 0: calls sev_handler()->wake_up() CPU 1: wakes up; finishes processing cmd #1 CPU 1: submits SEV cmd #2 CPU 1: calls wait_event_timeout() PSP: finishes processing cmd #2; interrupt status is still set; no interrupt CPU 0: clears intsts CPU 0: exits psp_irq_handler() CPU 1: wait_event_timeout() times out; psp_dead=true
Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Cc: stable@vger.kernel.org Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17 |
|
#
7ccc4f4e |
| 10-Mar-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - Add support for an interface for platform features
Some platforms with a PSP support an interface for features that interact directly with the PSP instead of through a SEV or TEE envir
crypto: ccp - Add support for an interface for platform features
Some platforms with a PSP support an interface for features that interact directly with the PSP instead of through a SEV or TEE environment.
Initialize this interface so that other drivers can consume it. These drivers may either be subdrivers for the ccp module or external modules. For external modules, export a symbol for them to utilize.
Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
a7ca7bbd |
| 10-Mar-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - Drop TEE support for IRQ handler
The only PSP mailbox that currently supports interrupt on completion is the SEV mailbox. Drop the dead code for the TEE subdriver to potentially call
crypto: ccp - Drop TEE support for IRQ handler
The only PSP mailbox that currently supports interrupt on completion is the SEV mailbox. Drop the dead code for the TEE subdriver to potentially call it.
Acked-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
4e2c8794 |
| 31-Mar-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - When TSME and SME both detected notify user
CC_ATTR_HOST_MEM_ENCRYPT is used to relay that memory encryption has been activated by the kernel.
As it's technically possible to enable b
crypto: ccp - When TSME and SME both detected notify user
CC_ATTR_HOST_MEM_ENCRYPT is used to relay that memory encryption has been activated by the kernel.
As it's technically possible to enable both SME and TSME at the same time, detect this scenario and notify the user that enabling TSME and SME at the same time is unnecessary.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
84ee393b |
| 31-Mar-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - Allow PSP driver to load without SEV/TEE support
Previously the PSP probe routine would fail if both SEV and TEE were missing. This is possibly the case for some client parts.
As cap
crypto: ccp - Allow PSP driver to load without SEV/TEE support
Previously the PSP probe routine would fail if both SEV and TEE were missing. This is possibly the case for some client parts.
As capabilities can now be accessed from userspace, it may still be useful to have the PSP driver finish loading so that those capabilities can be read.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
cac32cd4 |
| 31-Mar-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
crypto: ccp - cache capability into psp device
The results of the capability register will be used by future code at runtime rather than just initialization.
Acked-by: Tom Lendacky <thomas.lendacky
crypto: ccp - cache capability into psp device
The results of the capability register will be used by future code at runtime rather than just initialization.
Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24 |
|
#
15f7a4c6 |
| 03-Mar-2020 |
John Allen <john.allen@amd.com> |
crypto: ccp - Cleanup sp_dev_master in psp_dev_destroy()
Introduce clear_psp_master_device() to ensure that sp_dev_master gets properly cleared on the release of a psp device.
Fixes: 2a6170dfe755 (
crypto: ccp - Cleanup sp_dev_master in psp_dev_destroy()
Introduce clear_psp_master_device() to ensure that sp_dev_master gets properly cleared on the release of a psp device.
Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support") Signed-off-by: John Allen <john.allen@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2 |
|
#
33960acc |
| 04-Dec-2019 |
Rijo Thomas <Rijo-john.Thomas@amd.com> |
crypto: ccp - add TEE support for Raven Ridge
Adds a PCI device entry for Raven Ridge. Raven Ridge is an APU with a dedicated AMD Secure Processor having Trusted Execution Environment (TEE) support.
crypto: ccp - add TEE support for Raven Ridge
Adds a PCI device entry for Raven Ridge. Raven Ridge is an APU with a dedicated AMD Secure Processor having Trusted Execution Environment (TEE) support. The TEE provides a secure environment for running Trusted Applications (TAs) which implement security-sensitive parts of a feature.
This patch configures AMD Secure Processor's TEE interface by initializing a ring buffer (shared memory between Rich OS and Trusted OS) which can hold multiple command buffer entries. The TEE interface is facilitated by a set of CPU to PSP mailbox registers.
The next patch will address how commands are submitted to the ring buffer.
Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Co-developed-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
f100ab62 |
| 04-Dec-2019 |
Rijo Thomas <Rijo-john.Thomas@amd.com> |
crypto: ccp - check whether PSP supports SEV or TEE before initialization
Read PSP feature register to check for TEE (Trusted Execution Environment) support.
If neither SEV nor TEE is supported by
crypto: ccp - check whether PSP supports SEV or TEE before initialization
Read PSP feature register to check for TEE (Trusted Execution Environment) support.
If neither SEV nor TEE is supported by PSP, then skip PSP initialization.
Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Co-developed-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
b93566f1 |
| 04-Dec-2019 |
Rijo Thomas <Rijo-john.Thomas@amd.com> |
crypto: ccp - create a generic psp-dev file
The PSP (Platform Security Processor) provides support for key management commands in Secure Encrypted Virtualization (SEV) mode, along with software-base
crypto: ccp - create a generic psp-dev file
The PSP (Platform Security Processor) provides support for key management commands in Secure Encrypted Virtualization (SEV) mode, along with software-based Trusted Execution Environment (TEE) to enable third-party Trusted Applications.
Therefore, introduce psp-dev.c and psp-dev.h files, which can invoke SEV (or TEE) initialization based on platform feature support.
TEE interface support will be introduced in a later patch.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jens Wiklander <jens.wiklander@linaro.org> Co-developed-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12 |
|
#
ec310caf |
| 12-Nov-2019 |
Brijesh Singh <brijesh.singh@amd.com> |
crypto: ccp - add SEV command privilege separation
Currently, there is no privilege separation of the SEV command; you can run them all or none of them. This is less than ideal because it means that
crypto: ccp - add SEV command privilege separation
Currently, there is no privilege separation of the SEV command; you can run them all or none of them. This is less than ideal because it means that a compromise of the code which launches VMs could make permanent change to the SEV certifcate chain which will affect others.
These commands are required to attest the VM environment: - SEV_PDH_CERT_EXPORT - SEV_PLATFORM_STATUS - SEV_GET_{ID,ID2}
These commands manage the SEV certificate chain: - SEV_PEK_CERR_IMPORT - SEV_FACTORY_RESET - SEV_PEK_GEN - SEV_PEK_CSR - SEV_PDH_GEN
Lets add the CAP_SYS_ADMIN check for the group of the commands which alters the SEV certificate chain to provide some level of privilege separation.
Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Gary Hook <gary.hook@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Tested-by: David Rientjes <rientjes@google.com> Co-developed-by: David Rientjes <rientjes@google.com> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
03f008c5 |
| 21-Oct-2019 |
Hook, Gary <Gary.Hook@amd.com> |
crypto: ccp - Verify access to device registers before initializing
Check early whether device registers can be accessed. Some BIOSes have a broken security policy that prevents access to the device
crypto: ccp - Verify access to device registers before initializing
Check early whether device registers can be accessed. Some BIOSes have a broken security policy that prevents access to the device registers, and return values from ioread() can be misinterpreted. If a read of a feature register returns a -1, we may not be able to access any device register, so report the problem and suggestion, and return.
For the PSP, the feature register is checked. For the CCP, the queue register is checked.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
1d55fdc8 |
| 17-Oct-2019 |
Ashish Kalra <ashish.kalra@amd.com> |
crypto: ccp - Retry SEV INIT command in case of integrity check failure.
SEV INIT command loads the SEV related persistent data from NVS and initializes the platform context. The firmware validates
crypto: ccp - Retry SEV INIT command in case of integrity check failure.
SEV INIT command loads the SEV related persistent data from NVS and initializes the platform context. The firmware validates the persistent state. If validation fails, the firmware will reset the persisent state and return an integrity check failure status.
At this point, a subsequent INIT command should succeed, so retry the command. The INIT command retry is only done during driver initialization.
Additional enums along with SEV_RET_SECURE_DATA_INVALID are added to sev_ret_code to maintain continuity and relevance of enum values.
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Acked-by: David Rientjes <rientjes@google.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3 |
|
#
0fc5deae |
| 03-Oct-2019 |
Tom Lendacky <thomas.lendacky@amd.com> |
KVM: SVM: Remove unneeded WBINVD and DF_FLUSH when starting SEV guests
Performing a WBINVD and DF_FLUSH are expensive operations. The SEV support currently performs this WBINVD/DF_FLUSH combination
KVM: SVM: Remove unneeded WBINVD and DF_FLUSH when starting SEV guests
Performing a WBINVD and DF_FLUSH are expensive operations. The SEV support currently performs this WBINVD/DF_FLUSH combination when an SEV guest is terminated, so there is no need for it to be done before LAUNCH.
However, when the SEV firmware transitions the platform from UNINIT state to INIT state, all ASIDs will be marked invalid across all threads. Therefore, as part of transitioning the platform to INIT state, perform a WBINVD/DF_FLUSH after a successful INIT in the PSP/SEV device driver. Since the PSP/SEV device driver is x86 only, it can reference and use the WBINVD related functions directly.
Cc: Gary Hook <gary.hook@amd.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Tested-by: David Rientjes <rientjes@google.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1 |
|
#
83bf4251 |
| 12-Jul-2019 |
David Rientjes <rientjes@google.com> |
crypto: ccp - Fix SEV_VERSION_GREATER_OR_EQUAL
SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for example, because the minor version is not equal to or greater than the major
crypto: ccp - Fix SEV_VERSION_GREATER_OR_EQUAL
SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for example, because the minor version is not equal to or greater than the major.
Fix this and move to a static inline function for appropriate type checking.
Fixes: edd303ff0e9e ("crypto: ccp - Add DOWNLOAD_FIRMWARE SEV command") Reported-by: Cfir Cohen <cfir@google.com> Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.2, v5.1.16 |
|
#
600bac00 |
| 27-Jun-2019 |
Hook, Gary <Gary.Hook@amd.com> |
crypto: ccp - Switch to SPDX license identifiers
Add an SPDX identifier and remove any specific statements.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.
crypto: ccp - Switch to SPDX license identifiers
Add an SPDX identifier and remove any specific statements.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
d2912cb1 |
| 04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
f5a2aeb8 |
| 08-Apr-2019 |
Singh, Brijesh <brijesh.singh@amd.com> |
crypto: ccp - Do not free psp_master when PLATFORM_INIT fails
Currently, we free the psp_master if the PLATFORM_INIT fails during the SEV FW probe. If psp_master is freed then driver does not invoke
crypto: ccp - Do not free psp_master when PLATFORM_INIT fails
Currently, we free the psp_master if the PLATFORM_INIT fails during the SEV FW probe. If psp_master is freed then driver does not invoke the PSP FW. As per SEV FW spec, there are several commands (PLATFORM_RESET, PLATFORM_STATUS, GET_ID etc) which can be executed in the UNINIT state We should not free the psp_master when PLATFORM_INIT fails.
Fixes: 200664d5237f ("crypto: ccp: Add SEV support") Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Gary Hook <gary.hook@amd.com> Cc: stable@vger.kernel.org # 4.19.y Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.0.7, v5.0.6 |
|
#
d6112ea0 |
| 28-Mar-2019 |
Singh, Brijesh <brijesh.singh@amd.com> |
crypto: ccp - introduce SEV_GET_ID2 command
The current definition and implementation of the SEV_GET_ID command does not provide the length of the unique ID returned by the firmware. As per the firm
crypto: ccp - introduce SEV_GET_ID2 command
The current definition and implementation of the SEV_GET_ID command does not provide the length of the unique ID returned by the firmware. As per the firmware specification, the firmware may return an ID length that is not restricted to 64 bytes as assumed by the SEV_GET_ID command.
Introduce the SEV_GET_ID2 command to overcome with the SEV_GET_ID limitations. Deprecate the SEV_GET_ID in the favor of SEV_GET_ID2.
At the same time update SEV API web link.
Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Gary Hook <gary.hook@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Nathaniel McCallum <npmccallum@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24 |
|
#
7df5218d |
| 15-Feb-2019 |
Lendacky, Thomas <Thomas.Lendacky@amd.com> |
crypto: ccp - Update driver messages to remove some confusion
The current content of some of the driver messages and the way that they are issued results in some confusion, especially in the area of
crypto: ccp - Update driver messages to remove some confusion
The current content of some of the driver messages and the way that they are issued results in some confusion, especially in the area of the PSP as it relates to SEV support. If SEV is not supported, a message is issued that says "psp initialization failed." This makes it seem like there was a problem, when in fact, the PSP support is just disabled if SEV is not supported.
Update the driver to check SEV support a bit earlier and issue a debug- level message if SEV is not supported, followed by a debug-level message that the PSP is disabled. This way you will only see PSP messages if SEV is supported or if debug information is desired. Also, remove the overall "enabled" and "disabled" messages for the driver and rely on the CCP and PSP support to issue component-specific messages.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19 |
|
#
f8903b3e |
| 30-Jan-2019 |
Singh, Brijesh <brijesh.singh@amd.com> |
crypto: ccp - fix the SEV probe in kexec boot path
A kexec reboot may leave the firmware in INIT or WORKING state. Currently, we issue PLATFORM_INIT command during the probe without checking the cur
crypto: ccp - fix the SEV probe in kexec boot path
A kexec reboot may leave the firmware in INIT or WORKING state. Currently, we issue PLATFORM_INIT command during the probe without checking the current state. The PLATFORM_INIT command fails if the FW is already in INIT state. Lets check the current state, if FW is not in UNINIT state then transition it to UNINIT before initializing or upgrading the FW.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gary Hook <gary.hook@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11 |
|
#
fa5cd1c7 |
| 18-Dec-2018 |
Hook, Gary <Gary.Hook@amd.com> |
crypto: ccp - Update copyright notices and dates
Correct copyright dates for files that have had code added to them in 2018.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu
crypto: ccp - Update copyright notices and dates
Correct copyright dates for files that have had code added to them in 2018.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
96d4f267 |
| 03-Jan-2019 |
Linus Torvalds <torvalds@linux-foundation.org> |
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old
Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand.
It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact.
A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all.
This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
There were a couple of notable cases:
- csky still had the old "verify_area()" name as an alias.
- the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it)
- microblaze used the type argument for a debug printout
but other than those oddities this should be a total no-op patch.
I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|