Hi,
In this patch I've tried to summarize the recent discussion. I've defined the needed ioctls and a brief description of how the other relevant syscalls are used.
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org --- Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++ 2 files changed, 155 insertions(+) create mode 100644 include/linux/sechw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..a04c139 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sechw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sechw/tee.h b/include/linux/sechw/tee.h new file mode 100644 index 0000000..0c44d5d --- /dev/null +++ b/include/linux/sechw/tee.h @@ -0,0 +1,154 @@ +/* + * Copyright (c) 2015, Linaro Limited + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#ifndef __TEE_H +#define __TEE_H + +#include <linux/ioctl.h> +#include <linux/types.h> + +/* + * This file describes the API provided by the generic TEE driver to user + * space + */ + +#define TEE_GENDRV_MAJOR_VERSION 1 +#define TEE_GENDRV_MINOR_VERSION 0 + +/** + * struct tee_version - TEE versions + * @gendrv_major_version: Generic TEE driver major version + * @gendrv_minor_version: Generic TEE driver minor version + * @specdrv_major_version: Specific TEE driver major version + * @specdrv_minor_version: Specific TEE driver minor version + * @tee_api_major_version: Specific TEE API major version + * @tee_api_minor_version: Specific TEE API minor version + * @tee_os_major_version: Secure OS major version + * @tee_os_minor_version: Secure OS minor version + * @tee_api_uuid: Specific TEE API uuid + * @tee_os_uuid: Secure OS uuid + * + * Identifies the generic TEE driver, the specific TEE driver, which API + * is used to communicate with the Secure OS and the Secure OS itself. + * + * Unused fields are zeroed. + */ +struct tee_version { + uint32_t gendrv_major_version; + uint32_t gendrv_minor_version; + uint32_t specdrv_major_version; + uint32_t specdrv_minor_version; + uint32_t tee_api_major_version; + uint32_t tee_api_minor_version; + uint32_t tee_os_major_version; + uint32_t tee_os_minor_version; + uint8_t tee_api_uuid[16]; + uint8_t tee_os_uuid[16]; +}; + +/** + * struct tee_cmd_data - Opaque command argument + * @buf_ptr: A __user pointer to a command buffer + * @buf_len: Length of the buffer above + * + * Opaque command data which is passed on to the specific driver. The command + * buffer doesn't have to reside in shared memory. + */ +struct tee_cmd_data { + uint64_t buf_ptr; + uint64_t buf_len; +}; + +/** + * struct tee_shm_alloc_data - Shared memory allocate argument + * @size: Size of shared memory to allocate + * @flags: Flags to/from allocation, currently zero + * @fd: File descriptor of the shared memory + */ +struct tee_shm_alloc_data { + uint64_t size; + uint32_t flags; + int32_t fd; +}; + +/** + * struct tee_mem_share_data - share user space memory with Secure OS + * @ptr: A __user pointer to memory to share + * @size: Size of the memory to share + * @flags: Flags to/from sharing, currently set to zero by caller + * @pad: Padding, set to zero by caller + */ +struct tee_mem_share_data { + uint64_t ptr; + uint64_t size; + uint32_t flags; + uint32_t pad; +}; + +#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0 + +#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) + +/** + * TEE_IOC_VERSION - query version of drivers and secure OS + * + * Takes a tee_version struct and returns with the version numbers filled in. + */ +#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version) + +/** + * TEE_IOC_CMD - pass a command to the specific TEE driver + * + * Takes tee_cmd_data struct which is passed to the specific TEE driver. + */ +#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data) + +/** + * TEE_IOC_SHM_ALLOC - allocate shared memory + * + * Allocates shared memory between the user space process and secure OS. + * The returned file descriptor is used to map the shared memory into user + * space. The shared memory is freed when the descriptor is closed and the + * memory is unmapped. + */ +#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data) + +/** + * TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS + * + * Shares a portion of user space memory with secure OS. + */ +#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data) + +/** + * TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory + * + * Unshares a portion of previously shared user space memory. + */ +#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data) + +/* + * Five syscalls are used when communicating with the generic TEE driver. + * open(): opens the device associated with the driver + * ioctl(): as described above operating on the file descripto from open() + * close(): two cases + * - closes the device file descriptor + * - closes a file descriptor connected to allocated shared memory + * mmap(): maps shared memory into user space + * munmap(): unmaps previously shared memory + */ + +#endif /*__TEE_H*/
Hi Jens,
On 03/12/2015 08:14 AM, Jens Wiklander wrote:
Hi,
In this patch I've tried to summarize the recent discussion. I've defined the needed ioctls and a brief description of how the other relevant syscalls are used.
Good idea to make this a patch.
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++
'sechw' looks a bit weird to me; 'sec' or 'sec_hw' maybe?
2 files changed, 155 insertions(+) create mode 100644 include/linux/sechw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..a04c139 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sechw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sechw/tee.h b/include/linux/sechw/tee.h new file mode 100644 index 0000000..0c44d5d --- /dev/null +++ b/include/linux/sechw/tee.h @@ -0,0 +1,154 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to user
- space
- */
+#define TEE_GENDRV_MAJOR_VERSION 1 +#define TEE_GENDRV_MINOR_VERSION 0
+/**
- struct tee_version - TEE versions
- @gendrv_major_version: Generic TEE driver major version
- @gendrv_minor_version: Generic TEE driver minor version
- @specdrv_major_version: Specific TEE driver major version
- @specdrv_minor_version: Specific TEE driver minor version
- @tee_api_major_version: Specific TEE API major version
- @tee_api_minor_version: Specific TEE API minor version
- @tee_os_major_version: Secure OS major version
- @tee_os_minor_version: Secure OS minor version
- @tee_api_uuid: Specific TEE API uuid
- @tee_os_uuid: Secure OS uuid
- Identifies the generic TEE driver, the specific TEE driver, which API
- is used to communicate with the Secure OS and the Secure OS itself.
- Unused fields are zeroed.
- */
+struct tee_version {
- uint32_t gendrv_major_version;
- uint32_t gendrv_minor_version;
- uint32_t specdrv_major_version;
- uint32_t specdrv_minor_version;
- uint32_t tee_api_major_version;
- uint32_t tee_api_minor_version;
- uint32_t tee_os_major_version;
- uint32_t tee_os_minor_version;
- uint8_t tee_api_uuid[16];
- uint8_t tee_os_uuid[16];
+};
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
- uint64_t buf_ptr;
- uint64_t buf_len;
+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: File descriptor of the shared memory
"dma_buf file descriptor" maybe?
- */
+struct tee_shm_alloc_data {
- uint64_t size;
- uint32_t flags;
- int32_t fd;
+};
+/**
- struct tee_mem_share_data - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- @flags: Flags to/from sharing, currently set to zero by caller
- @pad: Padding, set to zero by caller
- */
+struct tee_mem_share_data {
- uint64_t ptr;
- uint64_t size;
- uint32_t flags;
- uint32_t pad;
+};
Here we may want to also support registration of a foreign dma_buf. I.e., user app obtains a file descriptor associated with a dma_buf (from another driver typically), then it registers the buffer for use on the trusted side. So, I would make it:
struct tee_mem_buf { uint64_t ptr; uint64_t size; };
struct tee_mem_dma_buf { uint32_t fd; uint32_t pad; };
struct tee_mem_share_data { union { struct tee_mem_buf buf; struct tee_mem_dma_buf dma_buf; }; uint32_t flags; uint32_t pad; };
flags would indicate whether .buf or .dmabuf is to be used.
Hi Jens and Jerome,
On Thu, Mar 12, 2015 at 09:50:43AM +0100, Jerome Forissier wrote:
Hi Jens,
On 03/12/2015 08:14 AM, Jens Wiklander wrote:
Hi,
In this patch I've tried to summarize the recent discussion. I've defined the needed ioctls and a brief description of how the other relevant syscalls are used.
Good idea to make this a patch.
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++
'sechw' looks a bit weird to me; 'sec' or 'sec_hw' maybe?
It's possible to change, I think this suggestion was coming from Javier initially.
2 files changed, 155 insertions(+) create mode 100644 include/linux/sechw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..a04c139 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sechw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sechw/tee.h b/include/linux/sechw/tee.h new file mode 100644 index 0000000..0c44d5d --- /dev/null +++ b/include/linux/sechw/tee.h @@ -0,0 +1,154 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to user
- space
- */
+#define TEE_GENDRV_MAJOR_VERSION 1 +#define TEE_GENDRV_MINOR_VERSION 0
+/**
- struct tee_version - TEE versions
- @gendrv_major_version: Generic TEE driver major version
- @gendrv_minor_version: Generic TEE driver minor version
- @specdrv_major_version: Specific TEE driver major version
- @specdrv_minor_version: Specific TEE driver minor version
- @tee_api_major_version: Specific TEE API major version
- @tee_api_minor_version: Specific TEE API minor version
- @tee_os_major_version: Secure OS major version
- @tee_os_minor_version: Secure OS minor version
- @tee_api_uuid: Specific TEE API uuid
- @tee_os_uuid: Secure OS uuid
- Identifies the generic TEE driver, the specific TEE driver, which API
- is used to communicate with the Secure OS and the Secure OS itself.
- Unused fields are zeroed.
- */
+struct tee_version {
- uint32_t gendrv_major_version;
- uint32_t gendrv_minor_version;
- uint32_t specdrv_major_version;
- uint32_t specdrv_minor_version;
- uint32_t tee_api_major_version;
- uint32_t tee_api_minor_version;
- uint32_t tee_os_major_version;
- uint32_t tee_os_minor_version;
- uint8_t tee_api_uuid[16];
- uint8_t tee_os_uuid[16];
+};
Seems like a lot of different version numbers here. I wonder if we want to expose much more than the TEE API version and eventually the Generic driver version? Can't the other versions be something that the specific driver etc provides themselves?
Also, even though it is convenient to get all this information in one go maybe we should consider reducing the struct to only contain one major and one minor value and then instead add a flag/type that tells which kind of version you are asking for.
struct tee_version { uint32_t major_version; uint32_t minor_version; uint64_t type; /* This is huge, but it's 64bits to make alignment of the struct good */ };
In type, a certain range could be defined (by us when creating this generic driver) and another range could be implementation defined. This would of course require the caller to do several calls instead of a single call to figure out misc versions, that is the drawback.
Version and UUID are related, but it would like to separate them apart. UUID is nothing TEE specific, that is something generic stated in RFC4122, which means that the struct we have been using so far is a good choice. I.e,
struct tee_uuid { uint32_t time_low; uint16_t time_mid; uint16_t time_hi_and_version; uint8_t clockseq_and_node[8]; };
Maybe we should consider splitting up clockseq_and_node into clk_seq_hi_res, clk_seq_low and node as in RFC4122?
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
- uint64_t buf_ptr;
- uint64_t buf_len;
+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: File descriptor of the shared memory
"dma_buf file descriptor" maybe?
- */
+struct tee_shm_alloc_data {
- uint64_t size;
- uint32_t flags;
- int32_t fd;
+};
+/**
- struct tee_mem_share_data - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- @flags: Flags to/from sharing, currently set to zero by caller
- @pad: Padding, set to zero by caller
- */
+struct tee_mem_share_data {
- uint64_t ptr;
- uint64_t size;
- uint32_t flags;
- uint32_t pad;
+};
Here we may want to also support registration of a foreign dma_buf. I.e., user app obtains a file descriptor associated with a dma_buf (from another driver typically), then it registers the buffer for use on the trusted side. So, I would make it:
struct tee_mem_buf { uint64_t ptr; uint64_t size; };
struct tee_mem_dma_buf { uint32_t fd; uint32_t pad; };
struct tee_mem_share_data { union { struct tee_mem_buf buf; struct tee_mem_dma_buf dma_buf; }; uint32_t flags; uint32_t pad; };
flags would indicate whether .buf or .dmabuf is to be used.
Sounds good.
I was just thinking about naming. I know that this isn't the most important thing to talk about initially. But still I'd like to comment on this. Already now in this proposal we have "shm", "mem", "mem_share". Do we actually need to mention "mem"? Isn't that implicitly understood? I.e, what about changing: from -> to tee_mem_buf -> tee_buf tee_mem_dma_buf -> tee_dma_buf tee_mem_share_data -> tee_shared_buf
However for "tee_shm_alloc_data" I still think it's good to have the "shm" in the name.
-- Jerome
+#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0
+#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size)
+/**
- TEE_IOC_VERSION - query version of drivers and secure OS
- Takes a tee_version struct and returns with the version numbers filled in.
- */
+#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version)
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
+/**
- TEE_IOC_SHM_ALLOC - allocate shared memory
- Allocates shared memory between the user space process and secure OS.
- The returned file descriptor is used to map the shared memory into user
- space. The shared memory is freed when the descriptor is closed and the
- memory is unmapped.
- */
+#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data)
+/**
- TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS
- Shares a portion of user space memory with secure OS.
- */
+#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data)
+/**
- TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory
- Unshares a portion of previously shared user space memory.
- */
+#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data)
+/*
- Five syscalls are used when communicating with the generic TEE driver.
- open(): opens the device associated with the driver
- ioctl(): as described above operating on the file descripto from open()
- close(): two cases
- closes the device file descriptor
- closes a file descriptor connected to allocated shared memory
- mmap(): maps shared memory into user space
- munmap(): unmaps previously shared memory
- */
+#endif /*__TEE_H*/
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Jens,
Good idea putting it into code. Thanks for doing it :)
On 12 Mar 2015, at 10:00, Joakim Bech joakim.bech@linaro.org wrote:
Hi Jens and Jerome,
On Thu, Mar 12, 2015 at 09:50:43AM +0100, Jerome Forissier wrote:
Hi Jens,
On 03/12/2015 08:14 AM, Jens Wiklander wrote:
Hi,
In this patch I've tried to summarize the recent discussion. I've defined the needed ioctls and a brief description of how the other relevant syscalls are used.
Good idea to make this a patch.
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++
'sechw' looks a bit weird to me; 'sec' or 'sec_hw' maybe?
It's possible to change, I think this suggestion was coming from Javier initially.
I am good with sec_hw if that makes more sense to you. Normally in /drivers/ we do not find “_” in names, that is why I proposed sechw. The idea is to have a “secure hawrdware” submodule where we can eventually move TPM and other secure coprocessors.
2 files changed, 155 insertions(+) create mode 100644 include/linux/sechw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..a04c139 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sechw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sechw/tee.h b/include/linux/sechw/tee.h new file mode 100644 index 0000000..0c44d5d --- /dev/null +++ b/include/linux/sechw/tee.h @@ -0,0 +1,154 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to user
- space
- */
+#define TEE_GENDRV_MAJOR_VERSION 1 +#define TEE_GENDRV_MINOR_VERSION 0
+/**
- struct tee_version - TEE versions
- @gendrv_major_version: Generic TEE driver major version
- @gendrv_minor_version: Generic TEE driver minor version
- @specdrv_major_version: Specific TEE driver major version
- @specdrv_minor_version: Specific TEE driver minor version
- @tee_api_major_version: Specific TEE API major version
- @tee_api_minor_version: Specific TEE API minor version
- @tee_os_major_version: Secure OS major version
- @tee_os_minor_version: Secure OS minor version
- @tee_api_uuid: Specific TEE API uuid
- @tee_os_uuid: Secure OS uuid
- Identifies the generic TEE driver, the specific TEE driver, which API
- is used to communicate with the Secure OS and the Secure OS itself.
- Unused fields are zeroed.
- */
+struct tee_version {
- uint32_t gendrv_major_version;
- uint32_t gendrv_minor_version;
- uint32_t specdrv_major_version;
- uint32_t specdrv_minor_version;
- uint32_t tee_api_major_version;
- uint32_t tee_api_minor_version;
- uint32_t tee_os_major_version;
- uint32_t tee_os_minor_version;
- uint8_t tee_api_uuid[16];
- uint8_t tee_os_uuid[16];
+};
Seems like a lot of different version numbers here. I wonder if we want to expose much more than the TEE API version and eventually the Generic driver version? Can't the other versions be something that the specific driver etc provides themselves?
Agreed.
Also, even though it is convenient to get all this information in one go maybe we should consider reducing the struct to only contain one major and one minor value and then instead add a flag/type that tells which kind of version you are asking for.
struct tee_version { uint32_t major_version; uint32_t minor_version; uint64_t type; /* This is huge, but it's 64bits to make alignment of the struct good */ };
+1
In type, a certain range could be defined (by us when creating this generic driver) and another range could be implementation defined. This would of course require the caller to do several calls instead of a single call to figure out misc versions, that is the drawback.
Version and UUID are related, but it would like to separate them apart. UUID is nothing TEE specific, that is something generic stated in RFC4122, which means that the struct we have been using so far is a good choice. I.e,
struct tee_uuid { uint32_t time_low; uint16_t time_mid; uint16_t time_hi_and_version; uint8_t clockseq_and_node[8]; };
Maybe we should consider splitting up clockseq_and_node into clk_seq_hi_res, clk_seq_low and node as in RFC4122?
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
- uint64_t buf_ptr;
- uint64_t buf_len;
+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: File descriptor of the shared memory
"dma_buf file descriptor" maybe?
- */
+struct tee_shm_alloc_data {
- uint64_t size;
- uint32_t flags;
- int32_t fd;
+};
+/**
- struct tee_mem_share_data - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- @flags: Flags to/from sharing, currently set to zero by caller
- @pad: Padding, set to zero by caller
- */
+struct tee_mem_share_data {
- uint64_t ptr;
- uint64_t size;
- uint32_t flags;
- uint32_t pad;
+};
Here we may want to also support registration of a foreign dma_buf. I.e., user app obtains a file descriptor associated with a dma_buf (from another driver typically), then it registers the buffer for use on the trusted side. So, I would make it:
struct tee_mem_buf { uint64_t ptr; uint64_t size; };
struct tee_mem_dma_buf { uint32_t fd; uint32_t pad; };
struct tee_mem_share_data { union { struct tee_mem_buf buf; struct tee_mem_dma_buf dma_buf; }; uint32_t flags; uint32_t pad; };
flags would indicate whether .buf or .dmabuf is to be used.
Sounds good.
Good idea.
I was just thinking about naming. I know that this isn't the most important thing to talk about initially. But still I'd like to comment on this. Already now in this proposal we have "shm", "mem", "mem_share". Do we actually need to mention "mem"? Isn't that implicitly understood? I.e, what about changing: from -> to tee_mem_buf -> tee_buf tee_mem_dma_buf -> tee_dma_buf tee_mem_share_data -> tee_shared_buf
However for "tee_shm_alloc_data" I still think it's good to have the "shm" in the name.
-- Jerome
+#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0
+#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size)
+/**
- TEE_IOC_VERSION - query version of drivers and secure OS
- Takes a tee_version struct and returns with the version numbers filled in.
- */
+#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version)
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
- TEE_IOC_SHM_ALLOC - allocate shared memory
- Allocates shared memory between the user space process and secure OS.
- The returned file descriptor is used to map the shared memory into user
- space. The shared memory is freed when the descriptor is closed and the
- memory is unmapped.
- */
+#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data)
+/**
- TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS
- Shares a portion of user space memory with secure OS.
- */
+#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data)
+/**
- TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory
- Unshares a portion of previously shared user space memory.
- */
+#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data)
+/*
- Five syscalls are used when communicating with the generic TEE driver.
- open(): opens the device associated with the driver
- ioctl(): as described above operating on the file descripto from open()
- close(): two cases
- closes the device file descriptor
- closes a file descriptor connected to allocated shared memory
- mmap(): maps shared memory into user space
- munmap(): unmaps previously shared memory
- */
+#endif /*__TEE_H*/
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
-- Regards, Joakim
Best, Javier
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
On 03/12/2015 06:56 PM, Javier González wrote:
Hi Jens,
Good idea putting it into code. Thanks for doing it :)
On 12 Mar 2015, at 10:00, Joakim Bech joakim.bech@linaro.org wrote:
Hi Jens and Jerome,
On Thu, Mar 12, 2015 at 09:50:43AM +0100, Jerome Forissier wrote:
Hi Jens,
On 03/12/2015 08:14 AM, Jens Wiklander wrote:
[...]
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++
'sechw' looks a bit weird to me; 'sec' or 'sec_hw' maybe?
It's possible to change, I think this suggestion was coming from Javier initially.
I am good with sec_hw if that makes more sense to you. Normally in /drivers/ we do not find “_” in names, that is why I proposed sechw. The idea is to have a “secure hawrdware” submodule where we can eventually move TPM and other secure coprocessors.
"Secure hardware" sounds good. The thing is, in French we tend to read "sechw" as "sech" + "w" because "ch" is a consonant sound on its own (like "sh" in English). Now, it is true that the kernel sources have dashes more often than underscores, so I change my vote to "sec-hw".
jerome@jfw540:~/work/linux (master)$ find . -type d -name '*-*' | wc -l 295 jerome@jfw540:~/work/linux (master)$ find . -type d -name '*_*' | wc -l 77
But then we shouldn't care too much about how a frog-eater would read the name of a kernel directory, right? ;)
Cheers,
On 12 Mar 2015, at 14:39, Jérôme Forissier jerome.forissier@linaro.org wrote:
On 03/12/2015 06:56 PM, Javier González wrote: Hi Jens,
Good idea putting it into code. Thanks for doing it :)
On 12 Mar 2015, at 10:00, Joakim Bech joakim.bech@linaro.org wrote:
Hi Jens and Jerome,
On Thu, Mar 12, 2015 at 09:50:43AM +0100, Jerome Forissier wrote: Hi Jens,
On 03/12/2015 08:14 AM, Jens Wiklander wrote:
[...]
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sechw/tee.h | 154 +++++++++++++++++++++++++++++++++++
'sechw' looks a bit weird to me; 'sec' or 'sec_hw' maybe?
It's possible to change, I think this suggestion was coming from Javier initially.
I am good with sec_hw if that makes more sense to you. Normally in /drivers/ we do not find “_” in names, that is why I proposed sechw. The idea is to have a “secure hawrdware” submodule where we can eventually move TPM and other secure coprocessors.
"Secure hardware" sounds good. The thing is, in French we tend to read "sechw" as "sech" + "w" because "ch" is a consonant sound on its own (like "sh" in English). Now, it is true that the kernel sources have dashes more often than underscores, so I change my vote to "sec-hw".
Thanks for the explanation. sec-hw sounds good :)
jerome@jfw540:~/work/linux (master)$ find . -type d -name '*-*' | wc -l 295 jerome@jfw540:~/work/linux (master)$ find . -type d -name '*_*' | wc -l 77
But then we shouldn't care too much about how a frog-eater would read the name of a kernel directory, right? ;)
:p
Cheers,
Jerome
Best, Javier
Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
There will be requests into secure world that will not go via this generic driver. PSCI is one example. On ARMv8 PSCI is handled in ARM-TF at EL3, but on ARMv7 it will probably be handled by the secure OS. If we compare with what's defined in SMC Calling Convention I think this driver will only be dealing with stuff that falls in the SMC ranges for Trusted Application and Trusted OS calls. The generic driver will not try to enforce that in any way since it doesn't even know what an SMC is.
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
-- Regards, Jens
Hi,
On 13 Mar 2015, at 05:22, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the client is in charge of holding that state when sending commands to the TEE.
With TEE_IOC_TASK I target use cases where the client requires one (and only one) command. In this way, the client would only send the command, and the driver would redirect the command to the default registered TrustZone driver (providing that more than one is instantiated simultaneously).
There will be requests into secure world that will not go via this generic driver. PSCI is one example. On ARMv8 PSCI is handled in ARM-TF at EL3, but on ARMv7 it will probably be handled by the secure OS. If we compare with what's defined in SMC Calling Convention I think this driver will only be dealing with stuff that falls in the SMC ranges for Trusted Application and Trusted OS calls. The generic driver will not try to enforce that in any way since it doesn't even know what an SMC is.
Agreed.
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I know that other TEEs are doing it too. I do not see a reason for not abstracting that behaviour and move specific OP-TEE parameters into an struct that is platform-dependent. I do that in the driver I first proposed for abstracting the structs handling OTZ parameters.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Yes. The question is whether we are in position to define some uuids for general operations.
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
-- Regards, Jens
Best, Javier
Hi,
On Fri, Mar 13, 2015 at 09:52:12AM -0400, Javier González wrote:
Hi,
On 13 Mar 2015, at 05:22, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the client is in charge of holding that state when sending commands to the TEE.
I agree with that. But in the data passed to TEE_IOC_CMD are typically a sub command which have some meaning to the specific driver. Some sub commands could relate to some session, while others could be stateless.
With TEE_IOC_TASK I target use cases where the client requires one (and only one) command. In this way, the client would only send the command, and the driver would redirect the command to the default registered TrustZone driver (providing that more than one is instantiated simultaneously).
Hmm, this suggests that there's only one tee-device in /dev. I've always though that we would have one tee-device for each registered driver. By opening that device you get a communication channel to that specific driver.
[...]
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I know that other TEEs are doing it too. I do not see a reason for not abstracting that behaviour and move specific OP-TEE parameters into an struct that is platform-dependent. I do that in the driver I first proposed for abstracting the structs handling OTZ parameters.
OP-TEE doesn't have something like TEE_IOC_LOAD_TS, OP-TEE OS load the TA via tee-supplicant so the client can't tell whether the application was just load or already resident.
I think we should try to keep the generic driver really simple in the first version. Both to save some time implementing it, but also to make the merge into the kernel easier. Once we have two or three specific drivers we know better what should be moved into the generic driver.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Yes. The question is whether we are in position to define some uuids for general operations.
I don't think it's needed for the first revision of the generic driver. If we see a need for making some uuid "well known" we can add that later.
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
-- Regards, Jens
Hi,
On 13 Mar 2015, at 11:38, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Fri, Mar 13, 2015 at 09:52:12AM -0400, Javier González wrote:
Hi,
On 13 Mar 2015, at 05:22, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
> +/** > + * TEE_IOC_CMD - pass a command to the specific TEE driver > + * > + * Takes tee_cmd_data struct which is passed to the specific TEE driver. > + */ > +#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data) > +
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the client is in charge of holding that state when sending commands to the TEE.
I agree with that. But in the data passed to TEE_IOC_CMD are typically a sub command which have some meaning to the specific driver. Some sub commands could relate to some session, while others could be stateless.
Good for me. Then we need to specify what the client is suppose to take care of in form of commands. This is, it is not only defining a command that express the statelessness, but defining what the client should keep for future communications.
With TEE_IOC_TASK I target use cases where the client requires one (and only one) command. In this way, the client would only send the command, and the driver would redirect the command to the default registered TrustZone driver (providing that more than one is instantiated simultaneously).
Hmm, this suggests that there's only one tee-device in /dev. I've always though that we would have one tee-device for each registered driver. By opening that device you get a communication channel to that specific driver.
You are right. It makes more sense to have several tee-devices to support platform-specific libraries (e.g., tee-suplicant).
[...]
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I know that other TEEs are doing it too. I do not see a reason for not abstracting that behaviour and move specific OP-TEE parameters into an struct that is platform-dependent. I do that in the driver I first proposed for abstracting the structs handling OTZ parameters.
OP-TEE doesn't have something like TEE_IOC_LOAD_TS, OP-TEE OS load the TA via tee-supplicant so the client can't tell whether the application was just load or already resident.
I think we should try to keep the generic driver really simple in the first version. Both to save some time implementing it, but also to make the merge into the kernel easier. Once we have two or three specific drivers we know better what should be moved into the generic driver.
Perfect.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Yes. The question is whether we are in position to define some uuids for general operations.
I don't think it's needed for the first revision of the generic driver. If we see a need for making some uuid "well known" we can add that later.
Same as above :)
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
My point is that you make it more difficult for applications to mishandle error codes. If checking a list of supported trusted services is part of the protocol then applications are more likely to ensure that the service exists before sending the command. They do something similar in TPM to check the version of the TPM (v.1.2, or 2.0) which is a good example of how applications would look at different TEE-frameworks.
-- Regards, Jens
Best, Javier.
On 03/13/2015 05:39 PM, Javier González wrote:
Hi,
On 13 Mar 2015, at 11:38, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi,
On Fri, Mar 13, 2015 at 09:52:12AM -0400, Javier González wrote:
Hi,
On 13 Mar 2015, at 05:22, Jens Wiklander jens.wiklander@linaro.org wrote:
[...]
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
My point is that you make it more difficult for applications to mishandle error codes. If checking a list of supported trusted services is part of the protocol then applications are more likely to ensure that the service exists before sending the command. They do something similar in TPM to check the version of the TPM (v.1.2, or 2.0) which is a good example of how applications would look at different TEE-frameworks.
Beware of the TOCTTOU problem [http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use%5D%21
Still I can see how getting a list of installed service can be useful. For instance to manage services (install/remove/update...). But is such a service likely to be implemented in normal world? It could also be seen as a debugging feature. With OP-TEE it's quite easy to check if a TA is installed with "ls /lib/teetz/*.ta" and maybe it's just that we want to allow?
On Fri, Mar 13, 2015 at 12:39:49PM -0400, Javier González wrote: [...]
>> +/** >> + * TEE_IOC_CMD - pass a command to the specific TEE driver >> + * >> + * Takes tee_cmd_data struct which is passed to the specific TEE driver. >> + */ >> +#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data) >> +
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the client is in charge of holding that state when sending commands to the TEE.
I agree with that. But in the data passed to TEE_IOC_CMD are typically a sub command which have some meaning to the specific driver. Some sub commands could relate to some session, while others could be stateless.
Good for me. Then we need to specify what the client is suppose to take care of in form of commands. This is, it is not only defining a command that express the statelessness, but defining what the client should keep for future communications.
Yes, that's a protocol between the client and the specific driver, the generic driver shouldn't care about it. For OP-TEE I guess we'll use a twist of the TEESMC interface.
With TEE_IOC_TASK I target use cases where the client requires one (and only one) command. In this way, the client would only send the command, and the driver would redirect the command to the default registered TrustZone driver (providing that more than one is instantiated simultaneously).
Hmm, this suggests that there's only one tee-device in /dev. I've always though that we would have one tee-device for each registered driver. By opening that device you get a communication channel to that specific driver.
You are right. It makes more sense to have several tee-devices to support platform-specific libraries (e.g., tee-suplicant).
That also means that we can have different permissions on different devices to make it harder for user space to DOS secure world.
[...]
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
I guess that the difference is that we make the check explicit, therefore we make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
My point is that you make it more difficult for applications to mishandle error codes. If checking a list of supported trusted services is part of the protocol then applications are more likely to ensure that the service exists before sending the command. They do something similar in TPM to check the version of the TPM (v.1.2, or 2.0) which is a good example of how applications would look at different TEE-frameworks.
As Jerome points out, there's the timing issue. But it also sounds like "nice to have", perhaps we can wait with this until after the first version?
-- Regards, Jens
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
Thanks Jens for the doc. However, it does not really answer: do you know if there are any performance drop using u64 types instead of native type on 32bits platforms? Or we simply don't care?
Pascal.
On 16 March 2015 at 10:26, Jens Wiklander jens.wiklander@linaro.org wrote:
On Fri, Mar 13, 2015 at 12:39:49PM -0400, Javier González wrote: [...]
>>> +/** >>> + * TEE_IOC_CMD - pass a command to the specific TEE driver >>> + * >>> + * Takes tee_cmd_data struct which is passed to the specific
TEE driver.
>>> + */ >>> +#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data) >>> +
Here, I would like to add TEE_IOC_TASK for stateless calls to the
TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the
specific
driver to add a state concept. Some requests through TEE_IOC_CMD
could be
handled without a state. Doesn't that cover what you're after?
Typically a client would have to open a “session” with the TEE that identifies that communication channel uniquely. This means that the
client
is in charge of holding that state when sending commands to the TEE.
I agree with that. But in the data passed to TEE_IOC_CMD are typically
a
sub command which have some meaning to the specific driver. Some sub commands could relate to some session, while others could be stateless.
Good for me. Then we need to specify what the client is suppose to take care of in form of commands. This is, it is not only defining a command that express the statelessness, but defining what the client should keep for future communications.
Yes, that's a protocol between the client and the specific driver, the generic driver shouldn't care about it. For OP-TEE I guess we'll use a twist of the TEESMC interface.
With TEE_IOC_TASK I target use cases where the client requires one
(and
only one) command. In this way, the client would only send the
command, and
the driver would redirect the command to the default registered
TrustZone
driver (providing that more than one is instantiated simultaneously).
Hmm, this suggests that there's only one tee-device in /dev. I've
always
though that we would have one tee-device for each registered driver. By opening that device you get a communication channel to that specific driver.
You are right. It makes more sense to have several tee-devices to support platform-specific libraries (e.g., tee-suplicant).
That also means that we can have different permissions on different devices to make it harder for user space to DOS secure world.
[...]
Suppose that a client know that it would like to communicate with
either
uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a
list
of uuids first and discover that none where available, what would be
the
difference?
I guess that the difference is that we make the check explicit,
therefore we
make it part of the protocol to check the list.
What do you gain? To me it just looks like added complexity.
My point is that you make it more difficult for applications to
mishandle error
codes. If checking a list of supported trusted services is part of the
protocol
then applications are more likely to ensure that the service exists
before sending
the command. They do something similar in TPM to check the version of
the TPM (v.1.2,
or 2.0) which is a good example of how applications would look at
different
TEE-frameworks.
As Jerome points out, there's the timing issue. But it also sounds like "nice to have", perhaps we can wait with this until after the first version?
-- Regards, Jens
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi,
On Mon, Mar 16, 2015 at 10:29:23AM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
Thanks Jens for the doc. However, it does not really answer: do you know if there are any performance drop using u64 types instead of native type on 32bits platforms? Or we simply don't care?
My best guess would be no (noticable) impact on optimized code. On client side perhaps 1 extra instruction 64-bit per field on a call and on kernel side 0 or 1 extra instructions per 64-bit field.
-- Regards, Jens
Hi Pascal
On 16.03.2015 11:29, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
Thanks Jens for the doc. However, it does not really answer: do you know if there are any performance drop using u64 types instead of native type on 32bits platforms? Or we simply don't care?
Pascal.
While a read to u64 might end up being a double load on 32bit platforms, the performance penalty will probably be minimum, since the they are in the same cache line and the read is performed seldom. The context switch(from the syscall) will have a much bigger performance penalty than reading a 64bit integer on a 32bit platform.
Also I think having the same interface between 32bit and 64bit kernels is a very good thing, since the same library will probably need to work with both.
Valentin
On Thu, Mar 12, 2015 at 03:00:56PM +0100, Joakim Bech wrote: [...]
+struct tee_version {
- uint32_t gendrv_major_version;
- uint32_t gendrv_minor_version;
- uint32_t specdrv_major_version;
- uint32_t specdrv_minor_version;
- uint32_t tee_api_major_version;
- uint32_t tee_api_minor_version;
- uint32_t tee_os_major_version;
- uint32_t tee_os_minor_version;
- uint8_t tee_api_uuid[16];
- uint8_t tee_os_uuid[16];
+};
Seems like a lot of different version numbers here. I wonder if we want to expose much more than the TEE API version and eventually the Generic driver version? Can't the other versions be something that the specific driver etc provides themselves?
Also, even though it is convenient to get all this information in one go maybe we should consider reducing the struct to only contain one major and one minor value and then instead add a flag/type that tells which kind of version you are asking for.
struct tee_version { uint32_t major_version; uint32_t minor_version; uint64_t type; /* This is huge, but it's 64bits to make alignment of the struct good */ };
In type, a certain range could be defined (by us when creating this generic driver) and another range could be implementation defined. This would of course require the caller to do several calls instead of a single call to figure out misc versions, that is the drawback.
What about reducing it to: struct tee_version { uint32_t gen_version; uint32_t spec_version; uint8_t spec_uuid[16]; };
This way the client can still identify the specific driver. The reason I'd like to keep the uuid is because that's what the specific driver will be looking for when identifying the secure OS, at least in the OP-TEE case. Another benefit is that we don't need to keep track of different types of specific drivers in a number since that's handled by the secure OS.
Version and UUID are related, but it would like to separate them apart. UUID is nothing TEE specific, that is something generic stated in RFC4122, which means that the struct we have been using so far is a good choice. I.e,
struct tee_uuid { uint32_t time_low; uint16_t time_mid; uint16_t time_hi_and_version; uint8_t clockseq_and_node[8]; };
Maybe we should consider splitting up clockseq_and_node into clk_seq_hi_res, clk_seq_low and node as in RFC4122?
I did a grep for uuid in the linux kernel, it seems what's used there if not just having it as I wrote above is the two types uuid_le and uuid_be from <linux/uuid.h>. The interface we're defining here is supposed to be a transport layer on which the client lib builds the high level stuff. I think it's overkill to go beyond what the kernel normally uses/does.
A benefit of keeping the uuid as I've defined it (no conversion between byte orders) is that the client lib can see if there's an endian missmatch between linux user space and secure OS. The client lib can then indicate that to the user space application if needed.
-- Regards, Jens
Hi,
Thanks for the input on the previous patch. Here's version two of the patch.
Changes: * Trimmed struct tee_version to what's needed to identify the specific driver * Renamed sechw to sec-hw * Added dma_buf stuff to struct tee_mem_share_data
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org --- Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sec-hw/tee.h | 167 +++++++++++++++++++++++++++++++++++ 2 files changed, 168 insertions(+) create mode 100644 include/linux/sec-hw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..3d55d8c 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sec-hw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sec-hw/tee.h b/include/linux/sec-hw/tee.h new file mode 100644 index 0000000..c8e749b --- /dev/null +++ b/include/linux/sec-hw/tee.h @@ -0,0 +1,167 @@ +/* + * Copyright (c) 2015, Linaro Limited + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#ifndef __TEE_H +#define __TEE_H + +#include <linux/ioctl.h> +#include <linux/types.h> + +/* + * This file describes the API provided by the generic TEE driver to user + * space + */ + +#define TEE_GENDRV_VERSION 1 + +/** + * struct tee_version - TEE versions + * @gen_version: Generic TEE driver version + * @spec_version: Specific TEE driver version + * @uuid: Specific TEE driver uuid, zero if not used + * + * Identifies the generic TEE driver, and the specific TEE driver. + */ +struct tee_version { + uint32_t gen_version; + uint32_t spec_version; + uint8_t uuid[16]; +}; + +/** + * struct tee_cmd_data - Opaque command argument + * @buf_ptr: A __user pointer to a command buffer + * @buf_len: Length of the buffer above + * + * Opaque command data which is passed on to the specific driver. The command + * buffer doesn't have to reside in shared memory. + */ +struct tee_cmd_data { + uint64_t buf_ptr; + uint64_t buf_len; +}; + +/** + * struct tee_shm_alloc_data - Shared memory allocate argument + * @size: Size of shared memory to allocate + * @flags: Flags to/from allocation, currently zero + * @fd: dma_buf file descriptor of the shared memory + */ +struct tee_shm_alloc_data { + uint64_t size; + uint32_t flags; + int32_t fd; +}; + +/** + * struct tee_mem_buf - share user space memory with Secure OS + * @ptr: A __user pointer to memory to share + * @size: Size of the memory to share + */ +struct tee_mem_buf { + uint64_t ptr; + uint64_t size; +}; + +/** + * struct tee_mem_dma_buf - share foreign dma_buf memory + * @fd: dma_buf file descriptor + * @pad: padding, set to zero by caller + */ +struct tee_mem_dma_buf { + int32_t fd; + uint32_t pad; +}; + + +/* + * Bits in struct tee_mem_share_data.flags + */ +#define TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER 0x1 /* use dma_buf field */ + +/** + * struct tee_mem_share_data - share memory with Secure OS + * @buf: share user space memory + * @dma_buf: share foreign dma_buf memory + * @flags: Flags to/from sharing, unused bits set to zero by caller + * @pad: Padding, set to zero by caller + * + * If TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER is set use the dma_buf field, else + * the buf field in the union. + */ +struct tee_mem_share_data { + union { + struct tee_mem_buf buf; + struct tee_mem_dma_buf dma_buf; + } + uint32_t flags; + uint32_t pad; +}; + +#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0 + +#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) + +/** + * TEE_IOC_VERSION - query version of drivers + * + * Takes a tee_version struct and returns with the version numbers filled in. + */ +#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version) + +/** + * TEE_IOC_CMD - pass a command to the specific TEE driver + * + * Takes tee_cmd_data struct which is passed to the specific TEE driver. + */ +#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data) + +/** + * TEE_IOC_SHM_ALLOC - allocate shared memory + * + * Allocates shared memory between the user space process and secure OS. + * The returned file descriptor is used to map the shared memory into user + * space. The shared memory is freed when the descriptor is closed and the + * memory is unmapped. + */ +#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data) + +/** + * TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS + * + * Shares a portion of user space memory with secure OS. + */ +#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data) + +/** + * TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory + * + * Unshares a portion of previously shared user space memory. + */ +#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data) + +/* + * Five syscalls are used when communicating with the generic TEE driver. + * open(): opens the device associated with the driver + * ioctl(): as described above operating on the file descripto from open() + * close(): two cases + * - closes the device file descriptor + * - closes a file descriptor connected to allocated shared memory + * mmap(): maps shared memory into user space + * munmap(): unmaps previously shared memory + */ + +#endif /*__TEE_H*/
Thanks Jens,
Even though the code not necessarily has to be stored in a central repository, we will very soon need to have the code "merged somewhere", which reflects our common thoughts on the driver and a place where patches sent on tee-dev mailing list will be merged after having them discussed.
In principle we need a repository and a gatekeeper/integrator.
We have several options, but I have two suggestions, either ... 1) Put a tree at git.linaro.org ... or ... 2) Put a tree at a developer account at GitHub.
git.linaro.org requires some minor setup, but I can fix that. Having it on a developer account is quick and easy. However I can imagine that not everyone thinks that this is a good idea. Thoughts?
I just want to once again emphasize that this is just a temporary thing. As soon as we start to get code upstreamed, the discussions should take place there instead, likewise with the source code.
The updated patch itself is a good start that I'm OK with (even though I still want to change a couple of names).
On Fri, Mar 13, 2015 at 11:19:26AM +0100, Jens Wiklander wrote:
Hi,
Thanks for the input on the previous patch. Here's version two of the patch.
Changes:
- Trimmed struct tee_version to what's needed to identify the specific driver
- Renamed sechw to sec-hw
- Added dma_buf stuff to struct tee_mem_share_data
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sec-hw/tee.h | 167 +++++++++++++++++++++++++++++++++++ 2 files changed, 168 insertions(+) create mode 100644 include/linux/sec-hw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..3d55d8c 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sec-hw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sec-hw/tee.h b/include/linux/sec-hw/tee.h new file mode 100644 index 0000000..c8e749b --- /dev/null +++ b/include/linux/sec-hw/tee.h @@ -0,0 +1,167 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to user
- space
- */
+#define TEE_GENDRV_VERSION 1
+/**
- struct tee_version - TEE versions
- @gen_version: Generic TEE driver version
- @spec_version: Specific TEE driver version
- @uuid: Specific TEE driver uuid, zero if not used
- Identifies the generic TEE driver, and the specific TEE driver.
- */
+struct tee_version {
- uint32_t gen_version;
- uint32_t spec_version;
- uint8_t uuid[16];
+};
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
- uint64_t buf_ptr;
- uint64_t buf_len;
+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: dma_buf file descriptor of the shared memory
- */
+struct tee_shm_alloc_data {
- uint64_t size;
- uint32_t flags;
- int32_t fd;
+};
+/**
- struct tee_mem_buf - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- */
+struct tee_mem_buf {
- uint64_t ptr;
- uint64_t size;
+};
+/**
- struct tee_mem_dma_buf - share foreign dma_buf memory
- @fd: dma_buf file descriptor
- @pad: padding, set to zero by caller
- */
+struct tee_mem_dma_buf {
- int32_t fd;
- uint32_t pad;
+};
+/*
- Bits in struct tee_mem_share_data.flags
- */
+#define TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER 0x1 /* use dma_buf field */
+/**
- struct tee_mem_share_data - share memory with Secure OS
- @buf: share user space memory
- @dma_buf: share foreign dma_buf memory
- @flags: Flags to/from sharing, unused bits set to zero by caller
- @pad: Padding, set to zero by caller
- If TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER is set use the dma_buf field, else
- the buf field in the union.
- */
+struct tee_mem_share_data {
- union {
struct tee_mem_buf buf;struct tee_mem_dma_buf dma_buf;- }
- uint32_t flags;
- uint32_t pad;
+};
+#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0
+#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size)
+/**
- TEE_IOC_VERSION - query version of drivers
- Takes a tee_version struct and returns with the version numbers filled in.
- */
+#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version)
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
+/**
- TEE_IOC_SHM_ALLOC - allocate shared memory
- Allocates shared memory between the user space process and secure OS.
- The returned file descriptor is used to map the shared memory into user
- space. The shared memory is freed when the descriptor is closed and the
- memory is unmapped.
- */
+#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data)
+/**
- TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS
- Shares a portion of user space memory with secure OS.
- */
+#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data)
+/**
- TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory
- Unshares a portion of previously shared user space memory.
- */
+#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data)
+/*
- Five syscalls are used when communicating with the generic TEE driver.
- open(): opens the device associated with the driver
- ioctl(): as described above operating on the file descripto from open()
- close(): two cases
- closes the device file descriptor
- closes a file descriptor connected to allocated shared memory
- mmap(): maps shared memory into user space
- munmap(): unmaps previously shared memory
- */
+#endif /*__TEE_H*/
1.9.1
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
+1 for GitHub. We can have an organization, as it is the case for OP-TEE. It allows multiple gatekeepers, and it looks less attached to someone but to a group of people. Could be "Tee-Dev".
Regards, Pascal.
On 13 March 2015 at 13:36, Joakim Bech joakim.bech@linaro.org wrote:
Thanks Jens,
Even though the code not necessarily has to be stored in a central repository, we will very soon need to have the code "merged somewhere", which reflects our common thoughts on the driver and a place where patches sent on tee-dev mailing list will be merged after having them discussed.
In principle we need a repository and a gatekeeper/integrator.
We have several options, but I have two suggestions, either ...
- Put a tree at git.linaro.org
... or ... 2) Put a tree at a developer account at GitHub.
git.linaro.org requires some minor setup, but I can fix that. Having it on a developer account is quick and easy. However I can imagine that not everyone thinks that this is a good idea. Thoughts?
I just want to once again emphasize that this is just a temporary thing. As soon as we start to get code upstreamed, the discussions should take place there instead, likewise with the source code.
The updated patch itself is a good start that I'm OK with (even though I still want to change a couple of names).
On Fri, Mar 13, 2015 at 11:19:26AM +0100, Jens Wiklander wrote:
Hi,
Thanks for the input on the previous patch. Here's version two of the patch.
Changes:
- Trimmed struct tee_version to what's needed to identify the specific
driver
- Renamed sechw to sec-hw
- Added dma_buf stuff to struct tee_mem_share_data
Regards, Jens
Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sec-hw/tee.h | 167
+++++++++++++++++++++++++++++++++++
2 files changed, 168 insertions(+) create mode 100644 include/linux/sec-hw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 8136e1f..3d55d8c 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: mailto:tlewis@mindspring.com 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sec-hw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sec-hw/tee.h b/include/linux/sec-hw/tee.h new file mode 100644 index 0000000..c8e749b --- /dev/null +++ b/include/linux/sec-hw/tee.h @@ -0,0 +1,167 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to
user
- space
- */
+#define TEE_GENDRV_VERSION 1
+/**
- struct tee_version - TEE versions
- @gen_version: Generic TEE driver version
- @spec_version: Specific TEE driver version
- @uuid: Specific TEE driver uuid, zero if not used
- Identifies the generic TEE driver, and the specific TEE driver.
- */
+struct tee_version {
uint32_t gen_version;uint32_t spec_version;uint8_t uuid[16];+};
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The
command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
uint64_t buf_ptr;uint64_t buf_len;+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: dma_buf file descriptor of the shared memory
- */
+struct tee_shm_alloc_data {
uint64_t size;uint32_t flags;int32_t fd;+};
+/**
- struct tee_mem_buf - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- */
+struct tee_mem_buf {
uint64_t ptr;uint64_t size;+};
+/**
- struct tee_mem_dma_buf - share foreign dma_buf memory
- @fd: dma_buf file descriptor
- @pad: padding, set to zero by caller
- */
+struct tee_mem_dma_buf {
int32_t fd;uint32_t pad;+};
+/*
- Bits in struct tee_mem_share_data.flags
- */
+#define TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER 0x1 /* use dma_buf
field */
+/**
- struct tee_mem_share_data - share memory with Secure OS
- @buf: share user space memory
- @dma_buf: share foreign dma_buf memory
- @flags: Flags to/from sharing, unused bits set to zero by caller
- @pad: Padding, set to zero by caller
- If TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER is set use the dma_buf field,
else
- the buf field in the union.
- */
+struct tee_mem_share_data {
union {struct tee_mem_buf buf;struct tee_mem_dma_buf dma_buf;}uint32_t flags;uint32_t pad;+};
+#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0
+#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr),
size)
+#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr),
size)
+/**
- TEE_IOC_VERSION - query version of drivers
- Takes a tee_version struct and returns with the version numbers
filled in.
- */
+#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version)
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
+/**
- TEE_IOC_SHM_ALLOC - allocate shared memory
- Allocates shared memory between the user space process and secure OS.
- The returned file descriptor is used to map the shared memory into
user
- space. The shared memory is freed when the descriptor is closed and
the
- memory is unmapped.
- */
+#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data)
+/**
- TEE_IOC_MEM_SHARE - share a portion of user space memory with secure
OS
- Shares a portion of user space memory with secure OS.
- */
+#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data)
+/**
- TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory
- Unshares a portion of previously shared user space memory.
- */
+#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data)
+/*
- Five syscalls are used when communicating with the generic TEE
driver.
- open(): opens the device associated with the driver
- ioctl(): as described above operating on the file descripto from
open()
- close(): two cases
- closes the device file descriptor
- closes a file descriptor connected to allocated shared memory
- mmap(): maps shared memory into user space
- munmap(): unmaps previously shared memory
- */
+#endif /*__TEE_H*/
1.9.1
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
-- Regards, Joakim B
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
On Fri, Mar 13, 2015 at 1:48 PM, Pascal Brand pascal.brand@linaro.org wrote:
+1 for GitHub. We can have an organization, as it is the case for OP-TEE. It allows multiple gatekeepers, and it looks less attached to someone but to a group of people. Could be "Tee-Dev".
+1 for GitHub, but I would say a developer account is enough for now. Jens, what do you think? I'm asking since you originated the code. Would you like to maintain that tree? Or would you prefer to leave it to someone else? (I know you are quite busy on other things). I can also take this role is everybody agrees.
On Fri, Mar 13, 2015 at 02:51:40PM +0100, Jérôme Forissier wrote:
On Fri, Mar 13, 2015 at 1:48 PM, Pascal Brand pascal.brand@linaro.org wrote:
+1 for GitHub. We can have an organization, as it is the case for OP-TEE. It allows multiple gatekeepers, and it looks less attached to someone but to a group of people. Could be "Tee-Dev".
+1 for GitHub, but I would say a developer account is enough for now. Jens, what do you think? I'm asking since you originated the code. Would you like to maintain that tree? Or would you prefer to leave it to someone else? (I know you are quite busy on other things). I can also take this role is everybody agrees.
I can do it on my account at github, we can always change later if there's a need. Once we're satisfied with the tee.h patch I'll push the first commit on a branch I'll communicate.
-- Regards, Jens
Hi Jens, If you want to host it in your github is fine with me. As I mentioned before though, when I first sent the patches I pointed to development taking place in [1], and gained some traction there; that is how I met Joakim in the first place. It is a project, so you can all get push/pull privileges. If we move development somewhere else we should stick to it.
[1] https://github.com/TrustZoneGenericDriver/linux
Best, Javier
On 13 Mar 2015, at 10:59, Jens Wiklander jens.wiklander@linaro.org wrote:
On Fri, Mar 13, 2015 at 02:51:40PM +0100, Jérôme Forissier wrote:
On Fri, Mar 13, 2015 at 1:48 PM, Pascal Brand pascal.brand@linaro.org wrote:
+1 for GitHub. We can have an organization, as it is the case for OP-TEE. It allows multiple gatekeepers, and it looks less attached to someone but to a group of people. Could be "Tee-Dev".
+1 for GitHub, but I would say a developer account is enough for now. Jens, what do you think? I'm asking since you originated the code. Would you like to maintain that tree? Or would you prefer to leave it to someone else? (I know you are quite busy on other things). I can also take this role is everybody agrees.
I can do it on my account at github, we can always change later if there's a need. Once we're satisfied with the tee.h patch I'll push the first commit on a branch I'll communicate.
-- Regards, Jens
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Javier,
On Fri, Mar 13, 2015 at 12:26:25PM -0400, Javier González wrote:
Hi Jens, If you want to host it in your github is fine with me. As I mentioned before though, when I first sent the patches I pointed to development taking place in [1], and gained some traction there; that is how I met Joakim in the first place. It is a project, so you can all get push/pull privileges. If we move development somewhere else we should stick to it.
Sounds good, let's use that.
-- Regards, Jens
On 13 March 2015 at 18:03, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Javier,
On Fri, Mar 13, 2015 at 12:26:25PM -0400, Javier González wrote:
Hi Jens, If you want to host it in your github is fine with me. As I mentioned before though, when I first sent the patches I pointed to development taking place in [1], and gained some traction there; that is
how
I met Joakim in the first place. It is a project, so you can all get
push/pull
privileges. If we move development somewhere else we should stick to it.
Sounds good, let's use that.
+1
-- Regards, Jens
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Regards, Joakim
Hi, I'm on my went back from from NYC. I'll set up privileges as soon as I'm back in Denmark.
Best, Javier.
On 13 Mar 2015, at 13:04, Joakim Bech joakim.bech@linaro.org wrote:
On 13 March 2015 at 18:03, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Javier,
On Fri, Mar 13, 2015 at 12:26:25PM -0400, Javier González wrote:
Hi Jens, If you want to host it in your github is fine with me. As I mentioned before though, when I first sent the patches I pointed to development taking place in [1], and gained some traction there; that is how I met Joakim in the first place. It is a project, so you can all get push/pull privileges. If we move development somewhere else we should stick to it.
Sounds good, let's use that.
+1
-- Regards, Jens
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Regards, Joakim
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
Regards, Pascal.
On 13 March 2015 at 20:11, Javier González javigon.napster@gmail.com wrote:
Hi, I'm on my went back from from NYC. I'll set up privileges as soon as I'm back in Denmark.
Best, Javier.
On 13 Mar 2015, at 13:04, Joakim Bech joakim.bech@linaro.org wrote:
On 13 March 2015 at 18:03, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Javier,
On Fri, Mar 13, 2015 at 12:26:25PM -0400, Javier González wrote:
Hi Jens, If you want to host it in your github is fine with me. As I mentioned before though, when I first sent the patches I pointed to development taking place in [1], and gained some traction there; that
is how
I met Joakim in the first place. It is a project, so you can all get
push/pull
privileges. If we move development somewhere else we should stick to it.
Sounds good, let's use that.
+1
-- Regards, Jens
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Regards, Joakim
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens
Hi, I guess we can move development in the future. For now, my understanding is that OP-TEE is also TrustZone-centric "The optee_os git, contains the source code for the TEE in Linux using the ARM(R) TrustZone(R) technology.”
But of course, if we want to abstract TrustZone we can call it TEE generic driver (even though TEE is tightly coupled with TrustZone as for today)
Best, Javier
On 16 Mar 2015, at 09:47, Pascal Brand pascal.brand@linaro.org wrote:
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander <jens.wiklander@linaro.org mailto:jens.wiklander@linaro.org> wrote: Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens
Hi Javier,
OP-TEE is *not* TrustZone centric. What we have on github only contains TZ code as it is driven by Linaro, which focus on arm architecture. But the code is split into generic code and arm code.
In STM, we are using OP-TEE for TZ GP TEE and for a dedicated secure copro (LX / st231). The source code is under the same repo, with an extra architecture. Same on the linux driver side. We are using the OPTEE one, and have added a specific backend which targets our specific copro, which is not TrustZone.
Best regards, Pascal.
On 16 March 2015 at 11:11, Javier González javigon.napster@gmail.com wrote:
Hi, I guess we can move development in the future. For now, my understanding is that OP-TEE is also TrustZone-centric "The optee_os git, contains the source code for the TEE in Linux using the ARM(R) TrustZone(R) technology.”
But of course, if we want to abstract TrustZone we can call it TEE generic driver (even though TEE is tightly coupled with TrustZone as for today)
Best, Javier
On 16 Mar 2015, at 09:47, Pascal Brand pascal.brand@linaro.org wrote:
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens
Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
On 16 Mar 2015, at 12:22, Pascal Brand pascal.brand@linaro.org wrote:
Hi Javier,
OP-TEE is *not* TrustZone centric. What we have on github only contains TZ code as it is driven by Linaro, which focus on arm architecture. But the code is split into generic code and arm code.
In STM, we are using OP-TEE for TZ GP TEE and for a dedicated secure copro (LX / st231). The source code is under the same repo, with an extra architecture. Same on the linux driver side. We are using the OPTEE one, and have added a specific backend which targets our specific copro, which is not TrustZone.
Best regards, Pascal.
On 16 March 2015 at 11:11, Javier González <javigon.napster@gmail.com mailto:javigon.napster@gmail.com> wrote: Hi, I guess we can move development in the future. For now, my understanding is that OP-TEE is also TrustZone-centric "The optee_os git, contains the source code for the TEE in Linux using the ARM(R) TrustZone(R) technology.”
But of course, if we want to abstract TrustZone we can call it TEE generic driver (even though TEE is tightly coupled with TrustZone as for today)
Best, Javier
On 16 Mar 2015, at 09:47, Pascal Brand <pascal.brand@linaro.org mailto:pascal.brand@linaro.org> wrote:
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander <jens.wiklander@linaro.org mailto:jens.wiklander@linaro.org> wrote: Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens
Hi Javier,
On Mon, Mar 16, 2015 at 01:11:15PM +0100, Javier González wrote:
Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
Could you please update the master branch so it is up to date with Linus branch? I.e: https://github.com/torvalds/linux
Hello guys,
I have been following this for a few days, but did not find the time to see how we could integrate with it yet... Thanks for this effort!
On 17/03/15 09:45, Joakim Bech wrote:
Hi Javier,
On Mon, Mar 16, 2015 at 01:11:15PM +0100, Javier González wrote:
Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
Could you please update the master branch so it is up to date with Linus branch? I.e: https://github.com/torvalds/linux
Beware that if this code depends on the latest and greatest vanilla kernel, it may not be compatible with older kernels. It will need to be based on the latest once it's ready to be pushed upstream, but for now I see no urgency as it first needs to be tested on the existing platforms...
Regards, Hervé
Hi, Joakim: I will rebase Linus’ branch with my patches. We can take it from there and branch as necessary. Herve: I will maintain a history. This is, I will keep branches for old kernels. This will help us testing existing platforms/deployments. In https://github.com/TrustZoneGenericDriver/ you can find patches that apply to 3.8. There are some versions missing in the middle, but still.
Best, Javier
On 17 Mar 2015, at 09:50, Hervé Fache herve.fache@trustonic.com wrote:
Hello guys,
I have been following this for a few days, but did not find the time to see how we could integrate with it yet... Thanks for this effort!
On 17/03/15 09:45, Joakim Bech wrote:
Hi Javier,
On Mon, Mar 16, 2015 at 01:11:15PM +0100, Javier González wrote:
Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
Could you please update the master branch so it is up to date with Linus branch? I.e: https://github.com/torvalds/linux
Beware that if this code depends on the latest and greatest vanilla kernel, it may not be compatible with older kernels. It will need to be based on the latest once it's ready to be pushed upstream, but for now I see no urgency as it first needs to be tested on the existing platforms...
Regards, Hervé
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
Hi, It is done. Master is clean and updated. tz_driver_first contains the exact patches I sent to LKLM in December, with 2 minor modifications in the Makefile due to a conflict. The patches should apply backwards until 3.8 (only the Makefile will give a conflict).
Best, Javier
On 17 Mar 2015, at 09:54, Javier González javigon.napster@gmail.com wrote:
Hi, Joakim: I will rebase Linus’ branch with my patches. We can take it from there and branch as necessary. Herve: I will maintain a history. This is, I will keep branches for old kernels. This will help us testing existing platforms/deployments. In https://github.com/TrustZoneGenericDriver/ you can find patches that apply to 3.8. There are some versions missing in the middle, but still.
Best, Javier
On 17 Mar 2015, at 09:50, Hervé Fache herve.fache@trustonic.com wrote:
Hello guys,
I have been following this for a few days, but did not find the time to see how we could integrate with it yet... Thanks for this effort!
On 17/03/15 09:45, Joakim Bech wrote:
Hi Javier,
On Mon, Mar 16, 2015 at 01:11:15PM +0100, Javier González wrote:
Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
Could you please update the master branch so it is up to date with Linus branch? I.e: https://github.com/torvalds/linux
Beware that if this code depends on the latest and greatest vanilla kernel, it may not be compatible with older kernels. It will need to be based on the latest once it's ready to be pushed upstream, but for now I see no urgency as it first needs to be tested on the existing platforms...
Regards, Hervé
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
+1 for github too. Not sure how you feel about it, but I started this when I submitted the driver in the first place: https://github.com/TrustZoneGenericDriver/linux https://github.com/TrustZoneGenericDriver/linux
Best, Javier
On 13 Mar 2015, at 08:48, Pascal Brand pascal.brand@linaro.org wrote:
+1 for GitHub. We can have an organization, as it is the case for OP-TEE. It allows multiple gatekeepers, and it looks less attached to someone but to a group of people. Could be "Tee-Dev".
Regards, Pascal.
On 13 March 2015 at 13:36, Joakim Bech <joakim.bech@linaro.org mailto:joakim.bech@linaro.org> wrote: Thanks Jens,
Even though the code not necessarily has to be stored in a central repository, we will very soon need to have the code "merged somewhere", which reflects our common thoughts on the driver and a place where patches sent on tee-dev mailing list will be merged after having them discussed.
In principle we need a repository and a gatekeeper/integrator.
We have several options, but I have two suggestions, either ...
- Put a tree at git.linaro.org http://git.linaro.org/
... or ... 2) Put a tree at a developer account at GitHub.
git.linaro.org http://git.linaro.org/ requires some minor setup, but I can fix that. Having it on a developer account is quick and easy. However I can imagine that not everyone thinks that this is a good idea. Thoughts?
I just want to once again emphasize that this is just a temporary thing. As soon as we start to get code upstreamed, the discussions should take place there instead, likewise with the source code.
The updated patch itself is a good start that I'm OK with (even though I still want to change a couple of names).
On Fri, Mar 13, 2015 at 11:19:26AM +0100, Jens Wiklander wrote:
Hi,
Thanks for the input on the previous patch. Here's version two of the patch.
Changes:
- Trimmed struct tee_version to what's needed to identify the specific driver
- Renamed sechw to sec-hw
- Added dma_buf stuff to struct tee_mem_share_data
Regards, Jens
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org mailto:jens.wiklander@linaro.org>
Documentation/ioctl/ioctl-number.txt | 1 + include/linux/sec-hw/tee.h | 167 +++++++++++++++++++++++++++++++++++ 2 files changed, 168 insertions(+) create mode 100644 include/linux/sec-hw/tee.h
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 8136e1f..3d55d8c 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments 0xA3 80-8F Port ACL in development: <mailto:tlewis@mindspring.com mailto:tlewis@mindspring.com> 0xA3 90-9F linux/dtlk.h +0xA4 00-1F linux/sec-hw/tee.h Generic TEE driver 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: diff --git a/include/linux/sec-hw/tee.h b/include/linux/sec-hw/tee.h new file mode 100644 index 0000000..c8e749b --- /dev/null +++ b/include/linux/sec-hw/tee.h @@ -0,0 +1,167 @@ +/*
- Copyright (c) 2015, Linaro Limited
- This software is licensed under the terms of the GNU General Public
- License version 2, as published by the Free Software Foundation, and
- may be copied, distributed, and modified under those terms.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- */
+#ifndef __TEE_H +#define __TEE_H
+#include <linux/ioctl.h> +#include <linux/types.h>
+/*
- This file describes the API provided by the generic TEE driver to user
- space
- */
+#define TEE_GENDRV_VERSION 1
+/**
- struct tee_version - TEE versions
- @gen_version: Generic TEE driver version
- @spec_version: Specific TEE driver version
- @uuid: Specific TEE driver uuid, zero if not used
- Identifies the generic TEE driver, and the specific TEE driver.
- */
+struct tee_version {
uint32_t gen_version;uint32_t spec_version;uint8_t uuid[16];+};
+/**
- struct tee_cmd_data - Opaque command argument
- @buf_ptr: A __user pointer to a command buffer
- @buf_len: Length of the buffer above
- Opaque command data which is passed on to the specific driver. The command
- buffer doesn't have to reside in shared memory.
- */
+struct tee_cmd_data {
uint64_t buf_ptr;uint64_t buf_len;+};
+/**
- struct tee_shm_alloc_data - Shared memory allocate argument
- @size: Size of shared memory to allocate
- @flags: Flags to/from allocation, currently zero
- @fd: dma_buf file descriptor of the shared memory
- */
+struct tee_shm_alloc_data {
uint64_t size;uint32_t flags;int32_t fd;+};
+/**
- struct tee_mem_buf - share user space memory with Secure OS
- @ptr: A __user pointer to memory to share
- @size: Size of the memory to share
- */
+struct tee_mem_buf {
uint64_t ptr;uint64_t size;+};
+/**
- struct tee_mem_dma_buf - share foreign dma_buf memory
- @fd: dma_buf file descriptor
- @pad: padding, set to zero by caller
- */
+struct tee_mem_dma_buf {
int32_t fd;uint32_t pad;+};
+/*
- Bits in struct tee_mem_share_data.flags
- */
+#define TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER 0x1 /* use dma_buf field */
+/**
- struct tee_mem_share_data - share memory with Secure OS
- @buf: share user space memory
- @dma_buf: share foreign dma_buf memory
- @flags: Flags to/from sharing, unused bits set to zero by caller
- @pad: Padding, set to zero by caller
- If TEE_MEM_SHARE_FLAG_FOREIGN_BUFFER is set use the dma_buf field, else
- the buf field in the union.
- */
+struct tee_mem_share_data {
union {struct tee_mem_buf buf;struct tee_mem_dma_buf dma_buf;}uint32_t flags;uint32_t pad;+};
+#define TEE_IOC_MAGIC 0xa4 +#define TEE_IOC_BASE 0
+#define _TEE_IOR(nr, size) _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size) +#define _TEE_IOWR(nr, size) _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + (nr), size)
+/**
- TEE_IOC_VERSION - query version of drivers
- Takes a tee_version struct and returns with the version numbers filled in.
- */
+#define TEE_IOC_VERSION _TEE_IOR(0, struct tee_version)
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
+/**
- TEE_IOC_SHM_ALLOC - allocate shared memory
- Allocates shared memory between the user space process and secure OS.
- The returned file descriptor is used to map the shared memory into user
- space. The shared memory is freed when the descriptor is closed and the
- memory is unmapped.
- */
+#define TEE_IOC_SHM_ALLOC _TEE_IOWR(2, struct tee_shm_alloc_data)
+/**
- TEE_IOC_MEM_SHARE - share a portion of user space memory with secure OS
- Shares a portion of user space memory with secure OS.
- */
+#define TEE_IOC_MEM_SHARE _TEE_IOWR(3, struct tee_mem_share_data)
+/**
- TEE_IOC_MEM_UNSHARE - unshares a portion shared user space memory
- Unshares a portion of previously shared user space memory.
- */
+#define TEE_IOC_MEM_UNSHARE _TEE_IOWR(4, struct tee_mem_share_data)
+/*
- Five syscalls are used when communicating with the generic TEE driver.
- open(): opens the device associated with the driver
- ioctl(): as described above operating on the file descripto from open()
- close(): two cases
- closes the device file descriptor
- closes a file descriptor connected to allocated shared memory
- mmap(): maps shared memory into user space
- munmap(): unmaps previously shared memory
- */
+#endif /*__TEE_H*/
1.9.1
Tee-dev mailing list Tee-dev@lists.linaro.org mailto:Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev http://lists.linaro.org/mailman/listinfo/tee-dev
-- Regards, Joakim B
Tee-dev mailing list Tee-dev@lists.linaro.org mailto:Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev http://lists.linaro.org/mailman/listinfo/tee-dev
Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev
-
Hervé Fache -
Javier González -
Jens Wiklander -
Joakim Bech -
Jérôme Forissier -
Pascal Brand -
Valentin Manea