aboutsummaryrefslogtreecommitdiff
path: root/drivers/tee/Kconfig
AgeCommit message (Collapse)AuthorFilesLines
2024-04-03tee: tstee: Add Trusted Services TEE driverBalint Dobszay1-0/+1
The Trusted Services project provides a framework for developing and deploying device Root of Trust services in FF-A Secure Partitions. The FF-A SPs are accessible through the FF-A driver, but this doesn't provide a user space interface. The goal of this TEE driver is to make Trusted Services SPs accessible for user space clients. All TS SPs have the same FF-A UUID, it identifies the RPC protocol used by TS. A TS SP can host one or more services, a service is identified by its service UUID. The same type of service cannot be present twice in the same SP. During SP boot each service in an SP is assigned an interface ID, this is just a short ID to simplify message addressing. There is 1:1 mapping between TS SPs and TEE devices, i.e. a separate TEE device is registered for each TS SP. This is required since contrary to the generic TEE design where memory is shared with the whole TEE implementation, in case of FF-A, memory is shared with a specific SP. A user space client has to be able to separately share memory with each SP based on its endpoint ID. Acked-by: Sumit Garg <[email protected]> Signed-off-by: Balint Dobszay <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
2022-04-05tee: combine "config" and "menu" for TEE's menuconfigJan Engelhardt1-4/+1
Don't let TEE occupy two lines in menuconfig when practically no other (sub)menu does either. Signed-off-by: Jan Engelhardt <[email protected]> Reviewed-by: Sumit Garg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
2020-05-28tee: fix crypto selectArnd Bergmann1-0/+1
When selecting a crypto cipher, we also need to select the subsystem itself: WARNING: unmet direct dependencies detected for CRYPTO_SHA1 Depends on [m]: CRYPTO [=m] Selected by [y]: - TEE [=y] && (HAVE_ARM_SMCCC [=n] || COMPILE_TEST [=y] || CPU_SUP_AMD [=y]) Selected by [m]: - CRYPTO_DEV_QAT [=m] && CRYPTO [=m] && CRYPTO_HW [=y] - CRYPTO_DEV_MEDIATEK [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && (ARM && ARCH_MEDIATEK || COMPILE_TEST [=y]) - CRYPTO_DEV_SAFEXCEL [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && (OF [=y] || PCI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] - CRYPTO_DEV_CCREE [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && OF [=y] && HAS_DMA [=y] - CRYPTO_DEV_SP_CCP [=y] && CRYPTO [=m] && CRYPTO_HW [=y] && CRYPTO_DEV_CCP [=y] && CRYPTO_DEV_CCP_DD [=m] && DMADEVICES [=y] Link: https://lore.kernel.org/r/[email protected] Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Vesa Jääskeläinen <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2020-05-11tee: add support for session's client UUID generationVesa Jääskeläinen1-0/+1
TEE Client API defines that from user space only information needed for specified login operations is group identifier for group based logins. REE kernel is expected to formulate trustworthy client UUID and pass that to TEE environment. REE kernel is required to verify that provided group identifier for group based logins matches calling processes group memberships. TEE specification only defines that the information passed from REE environment to TEE environment is encoded into on UUID. In order to guarantee trustworthiness of client UUID user space is not allowed to freely pass client UUID. UUIDv5 form is used encode variable amount of information needed for different login types. Signed-off-by: Vesa Jääskeläinen <[email protected]> [jw: remove unused variable application_id] Signed-off-by: Jens Wiklander <[email protected]>
2020-01-04tee: add AMD-TEE driverRijo Thomas1-1/+1
Adds AMD-TEE driver. * targets AMD APUs which has AMD Secure Processor with software-based Trusted Execution Environment (TEE) support * registers with TEE subsystem * defines tee_driver_ops function callbacks * kernel allocated memory is used as shared memory between normal world and secure world. * acts as REE (Rich Execution Environment) communication agent, which uses the services of AMD Secure Processor driver to submit commands for processing in TEE environment Cc: Ard Biesheuvel <[email protected]> Cc: Tom Lendacky <[email protected]> Acked-by: Jens Wiklander <[email protected]> Co-developed-by: Devaraj Rangasamy <[email protected]> Signed-off-by: Devaraj Rangasamy <[email protected]> Signed-off-by: Rijo Thomas <[email protected]> Reviewed-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-04tee: allow compilation of tee subsystem for AMD CPUsRijo Thomas1-1/+1
Allow compilation of tee subsystem for AMD's CPUs which have a dedicated AMD Secure Processor for Trusted Execution Environment (TEE). Acked-by: Jens Wiklander <[email protected]> Co-developed-by: Devaraj Rangasamy <[email protected]> Signed-off-by: Devaraj Rangasamy <[email protected]> Signed-off-by: Rijo Thomas <[email protected]> Reviewed-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1-0/+1
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-05-10tee: add ARM_SMCCC dependencyArnd Bergmann1-0/+1
For the moment, the tee subsystem only makes sense in combination with the op-tee driver that depends on ARM_SMCCC, so let's hide the subsystem from users that can't select that. Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2017-03-10tee: add OP-TEE driverJens Wiklander1-0/+10
Adds a OP-TEE driver which also can be compiled as a loadable module. * Targets ARM and ARM64 * Supports using reserved memory from OP-TEE as shared memory * Probes OP-TEE version using SMCs * Accepts requests on privileged and unprivileged device * Uses OPTEE message protocol version 2 to communicate with secure world Acked-by: Andreas Dannenberg <[email protected]> Tested-by: Jerome Forissier <[email protected]> (HiKey) Tested-by: Volodymyr Babchuk <[email protected]> (RCAR H3) Tested-by: Scott Branden <[email protected]> Reviewed-by: Javier González <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
2017-03-09tee: generic TEE subsystemJens Wiklander1-0/+8
Initial patch for generic TEE subsystem. This subsystem provides: * Registration/un-registration of TEE drivers. * Shared memory between normal world and secure world. * Ioctl interface for interaction with user space. * Sysfs implementation_id of TEE driver A TEE (Trusted Execution Environment) driver is a driver that interfaces with a trusted OS running in some secure environment, for example, TrustZone on ARM cpus, or a separate secure co-processor etc. The TEE subsystem can serve a TEE driver for a Global Platform compliant TEE, but it's not limited to only Global Platform TEEs. This patch builds on other similar implementations trying to solve the same problem: * "optee_linuxdriver" by among others Jean-michel DELORME<[email protected]> and Emmanuel MICHEL <[email protected]> * "Generic TrustZone Driver" by Javier González <[email protected]> Acked-by: Andreas Dannenberg <[email protected]> Tested-by: Jerome Forissier <[email protected]> (HiKey) Tested-by: Volodymyr Babchuk <[email protected]> (RCAR H3) Tested-by: Scott Branden <[email protected]> Reviewed-by: Javier González <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.