Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
shared memory from a dmabuf file descriptor.
This new ioctl will allow the Linux Kernel to register a buffer
to be used by the Secure Data Path OPTEE OS feature.
Please find more information here:
https://static.linaro.org/connect/san19/presentations/san19-107.pdf
Patch tested on Hikey 6220.
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
drivers/tee/tee_core.c | 38 +++++++++++++++
drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++-
include/linux/tee_drv.h | 11 +++++
include/uapi/linux/tee.h | 29 ++++++++++++
4 files changed, 175 insertions(+), 2 deletions(-)
--
2.25.0
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.19.0 is scheduled to be released on 2022-10-14. So, now is a
good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/5550
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related
to releases here:
https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
--
Jerome
Hi,
We don't have any topics for the meeting today, so let's cancel it.
The time slot we've allocated for this meeting is either bad or worse
for me so I'd like to try and find a new time slot. Please use the
doodle link [1] below to record your preferences. The doodle poll is
public so feel free to email me directly instead in case you're more
comfortable with that. This is my first time creating a doodle poll,
so apologies if I've made a mess of it.
As noted in the poll we're looking for a day and time in the fourth
week of the month. We're using the CET time zone as many of us are in
the time zone.
If you can't find any time that works for you please send me a mail
with more suitable times and I'll try to work out something. Let's
give this a week or so to possibly settle on a new time slot.
[1] https://doodle.com/meeting/participate/id/dJqR4Eyb
Thanks,
Jens
Hi All,
This series is just some refactoring in preparation to add FF-A v1.1
support. It doesn't have any memory layout or notification changes
supported in v1.1 yet.
Regards,
Sudeep
v2[2]->v3:
- Fixed the logic to set 32bit mode which was wrong.
- Ensured that we advance each partition info size by returned
size even if the size is greater than the partition_info structure,
we will still just copy the right size.
v1[1]->v2[2]:
- Merged dropping of ffa_ops in optee_ffa structure and using
ffa_dev->ops into single patch
- Added separate patch(didn't fit any patch strictly to fit in)
to rename ffa_dev_ops as ffa_ops as suggested by Sumit
- Fixed some minor comments, handling size > structure size in
partition_info_get and added extra parameter to ffa_features
to get both possible output/interface properties.
[1] https://lore.kernel.org/all/20220830100700.344594-1-sudeep.holla@arm.com
[2] https://lore.kernel.org/all/20220902124032.788488-1-sudeep.holla@arm.com
Sudeep Holla (10):
firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev
tee: optee: Drop ffa_ops in optee_ffa structure using ffa_dev->ops directly
firmware: arm_ffa: Remove ffa_dev_ops_get()
firmware: arm_ffa: Add support for querying FF-A features
firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supported
firmware: arm_ffa: Make memory apis ffa_device independent
firmware: arm_ffa: Rename ffa_dev_ops as ffa_ops
firmware: arm_ffa: Add v1.1 get_partition_info support
firmware: arm_ffa: Set up 32bit execution mode flag using partiion property
firmware: arm_ffa: Split up ffa_ops into info, message and memory operations
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 131 +++++++++++++++++++++++-------
drivers/tee/optee/ffa_abi.c | 46 +++++------
drivers/tee/optee/optee_private.h | 1 -
include/linux/arm_ffa.h | 36 +++++---
5 files changed, 151 insertions(+), 67 deletions(-)
--
2.37.3
Hi All,
This series is just some refactoring in preparation to add FF-A v1.1
support. It doesn't have any memory layout or notification changes
supported in v1.1 yet.
Regards,
Sudeep
v1[1]->v2:
- Merged dropping of ffa_ops in optee_ffa structure and using
ffa_dev->ops into single patch
- Added separate patch(didn't fit any patch strictly to fit in)
to rename ffa_dev_ops as ffa_ops as suggested by Sumit
- Fixed some minor comments, handling size > structure size in
partition_info_get and added extra parameter to ffa_features
to get both possible output/interface properties.
[1] https://lore.kernel.org/all/20220830100700.344594-1-sudeep.holla@arm.com/
Sudeep Holla (10):
firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev
tee: optee: Drop ffa_ops in optee_ffa structure using ffa_dev->ops directly
firmware: arm_ffa: Remove ffa_dev_ops_get()
firmware: arm_ffa: Add support for querying FF-A features
firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supported
firmware: arm_ffa: Make memory apis ffa_device independent
firmware: arm_ffa: Rename ffa_dev_ops as ffa_ops
firmware: arm_ffa: Add v1.1 get_partition_info support
firmware: arm_ffa: Set up 32bit execution mode flag using partiion property
firmware: arm_ffa: Split up ffa_ops into info, message and memory operations
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 130 +++++++++++++++++++++++-------
drivers/tee/optee/ffa_abi.c | 46 +++++------
drivers/tee/optee/optee_private.h | 1 -
include/linux/arm_ffa.h | 36 ++++++---
5 files changed, 150 insertions(+), 67 deletions(-)
--
2.37.3
+ TEE ML
On Fri, 2 Sept 2022 at 18:48, Maximilian Luz <luzmaximilian(a)gmail.com> wrote:
>
> Hi,
>
> On 9/2/22 09:26, Sumit Garg wrote:
> > Hi Maximilian,
> >
> > On 02/08/22 18:52, Maximilian Luz wrote:
>
> [...]
>
> >> Thanks for this information! So as far as I understand it, this is currently an
> >> interface to user-space only, i.e. does not allow in-kernel drivers for apps?
> >
> > The Linux TEE framework already provides an in-kernel interface to TEE as well via TEE bus [1]. There are already multiple kernel drivers [2] [3] [4] [5] [6] [7] using it. So an EFI driver can be an addition to that.
> >
> > Now coming on to TEE implementations, the drivers I mentioned are based on OP-TEE where devices are queried/enumerated during OP-TEE probe here [8]. So in similar manner QTEE smcinvoke driver should be able to register devices on the TEE bus.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc…
> >
> > [2] drivers/char/tpm/tpm_ftpm_tee.c
> >
> > [3] drivers/char/hw_random/optee-rng.c
> >
> > [4] drivers/firmware/arm_scmi/optee.c
> >
> > [5] security/keys/trusted-keys/trusted_tee.c
> >
> > [6] drivers/firmware/broadcom/tee_bnxt_fw.c
> >
> > [7] drivers/rtc/rtc-optee.c
> >
> > [8] drivers/tee/optee/device.c
>
> Thanks for those links!
>
> I think it would indeed be good if we could make it work via that
> interface and I guess that should generally be possible. As far as I can
> see, the biggest problem might be that the current firmware doesn't seem
> to use UUIDs, so I guess we might need to emulate them somehow.
>
Okay, so I had a brief look at your driver to get an idea how QTEE
identifies its trusted/secure applications. AFAIU, it uses constant
strings as follows:
#define QCTEE_UEFISEC_APP_NAME "qcom.tz.uefisecapp"
I think we should be able to extend the TEE bus concept to accept
constant strings as device IDs as well. So if a driver wants to
support both OP-TEE and QTEE based apps then it can put corresponding
identifiers (UUID or a constant string) in the TEE device match ID
table. This way we should be able to support other TEE implementations
as I think any other identifier apart from UUID can be represented as
a constant string.
If anyone else has any better then feel free to discuss.
-Sumit
> It would be great if someone with some actual knowledge of the firmware
> used on those devices could have a look at this and provide some
> insights.
>
> My plan for now is to hold off on the UEFI variable driver until we have
> a (proper) TEE driver, which unfortunately might be a bit out of my
> depth. I'm happy to help out in any way I can though.
>
> Regards,
> Max
Hi All,
This series is just some refactoring in preparation to add FF-A v1.1 support.
It doesn't have any memory layout or notification changes supported in v1.1
yet.
Regards,
Sudeep
Sudeep Holla (9):
firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev
tee: optee: Use ffa_dev->ops directly
firmware: arm_ffa: Remove ffa_dev_ops_get()
firmware: arm_ffa: Add support for querying FF-A features
firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supported
firmware: arm_ffa: Make memory apis ffa_device independent
firmware: arm_ffa: Add v1.1 get_partition_info support
tee: optee: Drop ffa_ops in optee_ffa structure
firmware: arm_ffa: Split up ffa_dev_ops into info, message and memory operations
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 111 ++++++++++++++++++++++--------
drivers/tee/optee/ffa_abi.c | 40 +++++------
drivers/tee/optee/optee_private.h | 1 -
include/linux/arm_ffa.h | 34 +++++----
5 files changed, 127 insertions(+), 63 deletions(-)
--
2.37.2