kernel/drivers/crypto/ccp/psp-dev.c, branch linux-5.1.y

crypto: ccp - Do not free psp_master when PLATFORM_INIT fails

2019-05-22T05:39:42Z

commit f5a2aeb8b254c764772729a6e48d4e0c914bb56a upstream. 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 Cc: Herbert Xu Cc: Gary Hook Cc: stable@vger.kernel.org # 4.19.y Signed-off-by: Brijesh Singh Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Update driver messages to remove some confusion

2019-02-22T04:47:27Z

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 Signed-off-by: Herbert Xu

crypto: ccp - fix the SEV probe in kexec boot path

2019-02-08T07:29:48Z

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 Cc: Tom Lendacky Cc: Gary Hook Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu

crypto: ccp - Update copyright notices and dates

2019-01-11T06:16:56Z

Correct copyright dates for files that have had code added to them in 2018. Signed-off-by: Gary R Hook Signed-off-by: Herbert Xu

Remove 'type' argument from access_ok() function

2019-01-04T02:57:57Z

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

crypto: ccp - Make function sev_get_firmware() static

2018-10-05T02:16:56Z

Fixes the following sparse warning: drivers/crypto/ccp/psp-dev.c:444:5: warning: symbol 'sev_get_firmware' was not declared. Should it be static? Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model") Signed-off-by: Wei Yongjun Signed-off-by: Herbert Xu

crypto: ccp - Allow SEV firmware to be chosen based on Family and Model

2018-09-21T05:24:52Z

During PSP initialization, there is an attempt to update the SEV firmware by looking in /lib/firmware/amd/. Currently, sev.fw is the expected name of the firmware blob. This patch will allow for firmware filenames based on the family and model of the processor. Model specific firmware files are given highest priority. Followed by firmware for a subset of models. Lastly, failing the previous two options, fallback to looking for sev.fw. Signed-off-by: Janakarajan Natarajan Reviewed-by: Tom Lendacky Acked-by: Gary R Hook Signed-off-by: Herbert Xu

crypto: ccp - Fix static checker warning

2018-09-21T05:24:52Z

Under certain configuration SEV functions can be defined as no-op. In such a case error can be uninitialized. Initialize the variable to 0. Cc: Dan Carpenter Reported-by: Dan Carpenter Signed-off-by: Janakarajan Natarajan Acked-by: Gary R Hook Signed-off-by: Herbert Xu

crypto: ccp - add timeout support in the SEV command

2018-09-04T03:37:04Z

Currently, the CCP driver assumes that the SEV command issued to the PSP will always return (i.e. it will never hang). But recently, firmware bugs have shown that a command can hang. Since of the SEV commands are used in probe routines, this can cause boot hangs and/or loss of virtualization capabilities. To protect against firmware bugs, add a timeout in the SEV command execution flow. If a command does not complete within the specified timeout then return -ETIMEOUT and stop the driver from executing any further commands since the state of the SEV firmware is unknown. Cc: Tom Lendacky Cc: Gary Hook Cc: Herbert Xu Cc: linux-kernel@vger.kernel.org Signed-off-by: Brijesh Singh Signed-off-by: Herbert Xu

crypto: ccp - Check for NULL PSP pointer at module unload

2018-08-03T10:06:05Z

Should the PSP initialization fail, the PSP data structure will be freed and the value contained in the sp_device struct set to NULL. At module unload, psp_dev_destroy() does not check if the pointer value is NULL and will end up dereferencing a NULL pointer. Add a pointer check of the psp_data field in the sp_device struct in psp_dev_destroy() and return immediately if it is NULL. Cc: # 4.16.x- Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support") Signed-off-by: Tom Lendacky Acked-by: Gary R Hook Signed-off-by: Herbert Xu