dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by <linux/dma-buf.h> work with
const dma_buf_ops. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
2026 112 0 2138 85a drivers/tee/tee_shm.o
File size After adding 'const':
text data bss dec hex filename
2138 0 0 2138 85a drivers/tee/tee_shm.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Fixes the static checker warning in optee_release().
error: uninitialized symbol 'parg'.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJZF2pwAAoJEHm+PkMAQRiG9aAIAJJyV6Ux9kaX+glqO3KIs0wm
0K/yqMOv1JTfJ1UUgY4iZbk5XOPPmXv1bdKJFECZfuAHdymJUF/RVNNvDlZbaLdd
K8vDEi92eRwcf07a5b/Q2F8yNfADKKmRAA/oAbuQLBhJ0dPHig70PIvi9gq9kqiE
Ft1MinbsZLavYatLm7oVDr/nsYebEDMGwTy0EX5bF2YjydfAlCvVWnI5ld5wisiV
0fQF4W7MMjjcpAzG8uq3atEB8iQcWS2Ykz2chZRbYzHcdV2WJW751Vge9xc05Hzi
rxlqn6peZFiFyM0qdPLhY0ktGzSTZcCFeb3aZicvm5aOamy2KJjOSZrEwjU8kts=
=VHpx
-----END PGP SIGNATURE-----
Merge tag 'v4.12-rc1' into fixes
We've received a few fixes branches with -rc1 as base, but our contents was
still at pre-rc1. Merge it in expliticly to make 'git merge --log' clear on
hat was actually merged.
Signed-off-by: Olof Johansson <olof@lixom.net>
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 <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This branch introduces a generic TEE framework in the kernel, to handle
trusted environemtns (security coprocessor or software implementations
such as OP-TEE/TrustZone). I'm sending it separately from the other
arm-soc driver changes to give it a little more visibility, once
the subsystem is merged, we will likely keep this in the arm₋soc
drivers branch or have the maintainers submit pull requests directly,
depending on the patch volume.
I have reviewed earlier versions in the past, and have reviewed
the latest version in person during Linaro Connect BUD17.
Here is my overall assessment of the subsystem:
* There is clearly demand for this, both for the generic
infrastructure and the specific OP-TEE implementation.
* The code has gone through a large number of reviews,
and the review comments have all been addressed, but
the reviews were not coming up with serious issues any more
and nobody volunteered to vouch for the quality.
* The user space ioctl interface is sufficient to work with the
OP-TEE driver, and it should in principle work with other
TEE implementations that follow the GlobalPlatform[1] standards,
but it might need to be extended in minor ways depending on
specific requirements of future TEE implementations
* The main downside of the API to me is how the user space
is tied to the TEE implementation in hardware or firmware,
but uses a generic way to communicate with it. This seems
to be an inherent problem with what it is trying to do,
and I could not come up with any better solution than what
is implemented here.
For a detailed history of the patch series, see
https://lkml.org/lkml/2017/3/10/1277
Conflicts: needs a fixup after the drm tree was merged, see
https://patchwork.kernel.org/patch/9691679/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAWRIRzWCrR//JCVInAQLKUhAAiJaBqb4uv5wDWKw8MVV5BbFjq6po/eMK
r3lgwyBGoRnrYiXo0z2eYNqpHsmNIGrL21qYMzaBGhVeaOOVPZT4q3zH+Se9Oo+J
HHZZ4J6Q9kDIUy9WkM7ybHVj3C0kQIn7H+/6zi2L97tMQJMZHI0jCSgDa6XPqHzh
G/vqVx5jlaFj6SvkLR0L0yWTe0wXTHoyObSCWsM/nV8AiTNhMD3kcTEOm0XHcAJB
k8ei/Pw2INOFZu1B0xpoRkWoAo6YKMcxQp9kiMkcEhChPIkNK+8+npYJ3fiogsii
BVTXC9Km2jmUfQ21Pegd2XbqzNGU1rJSdHGTyK2Oax+0J+C8xElGMs8U9tqXPqun
fWkSp0dl7Sk0f9Yhc8JBD1Tsbuo0H+TsMtQ6RNvlxLiNHE/5/bZBCeylvtoUyI+m
NcvP0x5QeBmkitz7zhYpjaSv5HjZG3PPO3pfaz0Stmen5ZM8DWB1TaS1Nn9MigHt
RGXlafc6dKybQQBLWDwStv7IkqDRYte+7pwmx+QFCRWj8+uFtTCDPLyaDUTwlErL
n4ztUL1RWiq48S+yJDJURM4mLpEMnJFFF4tiiHH8eUe2JE+CXwGxkT6BG62W71Oy
RosiJ84LmdoHRyHx6xmqpoDcL1WG57IgWt05SRUkQatA/ealGX88gguGEAWsPL0h
cnKPYkiYfug=
=VzpB
-----END PGP SIGNATURE-----
Merge tag 'armsoc-tee' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull TEE driver infrastructure and OP-TEE drivers from Arnd Bergmann:
"This introduces a generic TEE framework in the kernel, to handle
trusted environemtns (security coprocessor or software implementations
such as OP-TEE/TrustZone). I'm sending it separately from the other
arm-soc driver changes to give it a little more visibility, once the
subsystem is merged, we will likely keep this in the arm₋soc drivers
branch or have the maintainers submit pull requests directly,
depending on the patch volume.
I have reviewed earlier versions in the past, and have reviewed the
latest version in person during Linaro Connect BUD17.
Here is my overall assessment of the subsystem:
- There is clearly demand for this, both for the generic
infrastructure and the specific OP-TEE implementation.
- The code has gone through a large number of reviews, and the review
comments have all been addressed, but the reviews were not coming
up with serious issues any more and nobody volunteered to vouch for
the quality.
- The user space ioctl interface is sufficient to work with the
OP-TEE driver, and it should in principle work with other TEE
implementations that follow the GlobalPlatform[1] standards, but it
might need to be extended in minor ways depending on specific
requirements of future TEE implementations
- The main downside of the API to me is how the user space is tied to
the TEE implementation in hardware or firmware, but uses a generic
way to communicate with it. This seems to be an inherent problem
with what it is trying to do, and I could not come up with any
better solution than what is implemented here.
For a detailed history of the patch series, see
https://lkml.org/lkml/2017/3/10/1277"
* tag 'armsoc-tee' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arm64: dt: hikey: Add optee node
Documentation: tee subsystem and op-tee driver
tee: add OP-TEE driver
tee: generic TEE subsystem
dt/bindings: add bindings for optee
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 <dannenberg@ti.com>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
Tested-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Javier González <javier@javigon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
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<jean-michel.delorme@st.com> and
Emmanuel MICHEL <emmanuel.michel@st.com>
* "Generic TrustZone Driver" by Javier González <javier@javigon.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
Tested-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Javier González <javier@javigon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
