- OP-TEE - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

5 years, 5 months

1
0
0 0

[PATCH v4 RESEND] tee: add support for application-based session login methods

by Elvira Khabirova

This is both a resend and a request for comments. The main reason for implementing this was to be able to authorize access to particular TAs based on the applications that request it. Furthermore, being able to distinguish between different applications also allows having trusted storage per-application. I believe this functionality might be crucial to many users of op-tee. This patch provides two possible ways of calculating the application identifier strings. This also serves as a stub for other methods. Since there is no concept of "application" known to the Linux kernel, the two proposed methods are based on the calling task's executable: the executable file's path and its SELinux attributes. Some vendor-specific methods may employ a service running in userspace, but these two methods are the only ones that we came up with that are fully contained in the kernel and are usable (and we actually use one of the two methods suggested). There might be other valid definitions of application-based identifier strings. The GP TEE Client API specifies the credentials generated as "only depending on the identity of the application program", being "persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage"; not more specific than that. Perhaps some other properties of a running task can be used to calculate an app ID, for example, to not depend on having an executable file (which is admittedly a rare thing to come by), or to be able to distinguish between different scripts run with one interpreter (which is also rare since the TEE Client API is C-based). If you're interested in this patch, or if you're using application-based login methods but with a different scheme, I would love to hear your experiences. Maybe there are other methods to consider; maybe the proposed methods are enough. If you're interested in testing this patch out, there is a reviewed, good-to-go pull request in the optee_test repository: https://github.com/OP-TEE/optee_test/pull/468 >8------------------------------------------------------8< GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- Changes in v4: - Fix potential exe_file leaks. Changes in v3: - Remove free_app_id() and replace it with calls to kfree(). Changes in v2: - Rename some functions and variables to make them shorter. - Include linux/security.h unconditionally. - Restructure error handling in tee_session_calc_client_uuid(). --- drivers/tee/Kconfig | 29 ++++++++++ drivers/tee/tee_core.c | 126 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 147 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 6ade4a5c4840..510ef2fceb82 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,9 +7,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -21,7 +24,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +128,65 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + fput(exe_file); + + if (len < 0) + return ERR_PTR(len); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + fput(exe_file); + + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +259,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -218,6 +282,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -228,10 +300,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -244,10 +312,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + kfree(app_id_data); break; default: @@ -255,7 +362,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.29.2

5 years, 5 months

1
0
0 0

Re: Secure memory allocation

by Rouven Czerwinski

On Mon, 2020-12-07 at 16:48 +0000, Robert Deliën via OP-TEE wrote: > Hi, > > Again, thank you very much for your prompt answer. > > > Looks good, the tee_mm functions handle resource allocation typically > > virtual or physical memory. It doesn't touch the memory itself. The > > code above looks OK. Yep, the memory will be physically contiguous > > since the entire TA RAM range (represented here by tee_mm_sec_ddr) is > > mapped with physically contiguous memory. > > The code 'works' beautifully. That is; The FB addresses it produces seem plausible: > D/TC:0 0 imx_lcdif_init:334 fb[0] @0x88e00000 (pa 0x8e100000) > D/TC:0 0 imx_lcdif_init:334 fb[1] @0x88e96000 (pa 0x8e196000) > Even accessing the buffer using the corresponding virtual addresses produces no Abort faults. > > Unfortunately, it doesn't produce an image on the LCD either. However, if I (illegally) re-use part of shared memory as a frame buffer, I _do_ get an image. > Details from conf.mk: > CFG_DRAM_BASE = 0x80000000 > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > > Details from code: > fb_pa = 0x90000000 - FB_SIZE; > fb_va = (void *fb_pa, MEM_AREA_NSEC_SHM); > > We are starting to suspect that the LCD peripheral is denied access to the frame buffer by the TZ controller, and this specific peripheral's bus master doesn't seem to have corresponding Supervisor mode bits in the HP0 or SA register. > > Now I do know that this problem is beyond the scope of this mailing list, but if anybody on this list knows more about this, I'd be more than happy to hear about it! > Hm, since the LCDIF CSL register is lumped together with the PXP, you could try setting the SA bit for the PXP peripheral. Regards, Rouven Czerwinski

5 years, 5 months

2
1
0 0

Re: Secure memory allocation

by Jens Wiklander

Hi Robert, Some answers below. On Wed, Dec 2, 2020 at 1:00 PM Robert Deliën via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi, > > We are using op-tee 3.10 in our i.MX6UL-based product and we are running into a small problem we hope you can help us out with. Apologies for the large mail; It's mostly pictures. > > The nature of our product requires us to protect access to the display contents. To achieve this, we have added a display driver to op-tee and have allocated the frame buffers in op-tee too. > > We are conforming to the memory-map as layed out in .../core/arch/arm/include/mm/generic_ram_layout.h: > > TEE RAM layout without CFG_WITH_PAGER > > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ > | SDP test memory (optional) | > +----------------------------------+ <-- CFG_TZDRAM_START + CFG_TZDRAM_SIZE > > +----------------------------------+ <-- CFG_SHMEM_START > | Non-secure static SHM | > +----------------------------------+ <-- CFG_SHMEM_START + CFG_SHMEM_SIZE > > With this memory map in mind, we came up with the following solution: > > +----------------------------------+ <-- CFG_DRAM_BASE > | | > | Non-secure memory | > | | > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ <-- CFG_POS_SEC_FB0_START > | Secure frame buffer 0 | > +----------------------------------+ <-- CFG_POS_SEC_FB1_START > | Secure frame buffer 1 | > +----------------------------------+ <-- CFG_SHMEM_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) > | Non-secure static SHM | > +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > CFG_SEC_FB_SIZE = 0x00096000 > CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) > CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) > CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) > CFG_TZDRAM_SIZE = ($(CFG_SHMEM_START) - $(CFG_TZDRAM_START)) > > This solution keeps the frame buffers within the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE, but when booting the system, we notice an overlap between TA_RAM and both frame buffer areas: > > D/TC:0 dump_mmap_table:732 type TA_RAM va 0x88c00000..0x8a8fffff pa 0x8e100000..0x8fdfffff size 0x01d00000 (pgdir) > ... > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8ded4000..0x8df69fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8df6a000..0x8dffffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) > > Without fully comprehending how memory is allocated, we fear that this situation will allow TA's to be loaded into these frame buffer areas. > To mitigate this, we came up with this alternative: > > +----------------------------------+ <-- CFG_DRAM_BASE > | | > | Non-secure memory | > | | > +----------------------------------+ <-- CFG_TZDRAM_START > | TEE core secure RAM (TEE_RAM) | > +----------------------------------+ > | Trusted Application RAM (TA_RAM) | > +----------------------------------+ <-- CFG_POS_SEC_FB0_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) > | Secure frame buffer 0 | > +----------------------------------+ <-- CFG_POS_SEC_FB1_START > | Secure frame buffer 1 | > +----------------------------------+ <-- CFG_SHMEM_START > | Non-secure static SHM | > +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) > CFG_DDR_SIZE = 0x10000000 > CFG_SHMEM_SIZE = 0x00200000 > CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) > CFG_SEC_FB_SIZE = 0x00096000 > CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) > CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) > CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) > CFG_TZDRAM_SIZE = ($(CFG_POS_SEC_FB0_START) - $(CFG_TZDRAM_START)) > > This solution puts the frame buffers outside the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE so they no longer overlap with TA_RAM. However, when booting the system, op-tee panics: > > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c2d4000..0x8c369fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) > D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c36a000..0x8c3fffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) > ... > D/TC:0 dump_mmap_table:732 type TA_RAM va 0x8c400000..0x8dfd3fff pa 0x8e100000..0x8fcd3fff size 0x01bd4000 (smallpg) > ... > E/TC:0 0 check_phys_mem_is_outside:332 Non-sec mem (0x8fcd4000:0x12c000) overlaps map (type 12 0x8fd6a000:0x96000) > E/TC:0 0 Panic at core/arch/arm/mm/core_mmu.c:336 <check_phys_mem_is_outside> > E/TC:0 0 TEE load address @ 0x8e000000 > E/TC:0 0 Call stack: > E/TC:0 0 0x8e005621 > E/TC:0 0 0x8e01d397 > E/TC:0 0 0x8e005aaf > E/TC:0 0 0x8e004da7 > E/TC:0 0 0x8e000174 > > In this situation, the memory area intended for the frame buffers (0x8fd6a000:0x96000) is now implicitly regarded as non-secure RAM, regardless of us registering it as MEM_AREA_RAM_SEC in main.c: > > register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB0_START, CFG_SEC_FB_SIZE); > register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB1_START, CFG_SEC_FB_SIZE); > > Could you please confirm (or deny) that our first solution is the proper way to allocate these secure frame buffers and that they will not be overwritten by the process of loading TAs? It looks like something went wrong in the first solution. The failure in the last solution is because OP-TEE thinks that you've accidentally tried to configure non-secure memory as secure memory. > If this is not the proper way, could you give us some pointers on how to do this? We do not feel comfortable allocating such large areas on the heap because of good taste and because we're not sure yet whether or not there are additional alignment requirement for these frame buffers. Perhaps something similar to the Linux slab-allocator is available? I think the easiest is to allocate memory from the pool used for TAs with: mm = tee_mm_alloc(&tee_mm_sec_ddr, size); Until this mm is freed no one else will use the memory it represents. Returned memory is page aligned (based on CORE_MMU_USER_CODE_SHIFT). This depends on paging being disabled, which it seems it is for the IMX platforms. If paging would have been enabled this memory might have been less secure than what you require, depending on how the platform is configured. Cheers, Jens

5 years, 5 months

2
3
0 0

Linaro OP-TEE Contributions meeting October 2020

by Joakim Bech

Hi, LOC monthly meeting is planned to take place October 28th @ 16.00 (UTC+1). Connection details can be found in the meeting notes document (link below). Ilias and Jens will give an introduction to the secure partitions and StandaloneMM parts in OP-TEE. Other than that feel free to suggest topics you'd like to discuss (by replying to this email or write it directly in the meeting notes). Note that it's UTC+1 since we're moving to winter time in Sweden in a couple of days from now (previous LOC meetings have been UTC+2). Meeting details: --------------- Date/time: Wednesday October 28th(a)16.00 (UTC+1) https://everytimezone.com/s/9bfdb976 Invitation/connection details: In the meeting notes Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Regards, Joakim on behalf of the Linaro OP-TEE team

5 years, 5 months

1
3
0 0

Secure memory allocation

by Robert Deliën

Hi, We are using op-tee 3.10 in our i.MX6UL-based product and we are running into a small problem we hope you can help us out with. Apologies for the large mail; It's mostly pictures. The nature of our product requires us to protect access to the display contents. To achieve this, we have added a display driver to op-tee and have allocated the frame buffers in op-tee too. We are conforming to the memory-map as layed out in .../core/arch/arm/include/mm/generic_ram_layout.h: TEE RAM layout without CFG_WITH_PAGER +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ | SDP test memory (optional) | +----------------------------------+ <-- CFG_TZDRAM_START + CFG_TZDRAM_SIZE +----------------------------------+ <-- CFG_SHMEM_START | Non-secure static SHM | +----------------------------------+ <-- CFG_SHMEM_START + CFG_SHMEM_SIZE With this memory map in mind, we came up with the following solution: +----------------------------------+ <-- CFG_DRAM_BASE | | | Non-secure memory | | | +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ <-- CFG_POS_SEC_FB0_START | Secure frame buffer 0 | +----------------------------------+ <-- CFG_POS_SEC_FB1_START | Secure frame buffer 1 | +----------------------------------+ <-- CFG_SHMEM_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) | Non-secure static SHM | +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) CFG_DDR_SIZE = 0x10000000 CFG_SHMEM_SIZE = 0x00200000 CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) CFG_SEC_FB_SIZE = 0x00096000 CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) CFG_TZDRAM_SIZE = ($(CFG_SHMEM_START) - $(CFG_TZDRAM_START)) This solution keeps the frame buffers within the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE, but when booting the system, we notice an overlap between TA_RAM and both frame buffer areas: D/TC:0 dump_mmap_table:732 type TA_RAM va 0x88c00000..0x8a8fffff pa 0x8e100000..0x8fdfffff size 0x01d00000 (pgdir) ... D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8ded4000..0x8df69fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8df6a000..0x8dffffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) Without fully comprehending how memory is allocated, we fear that this situation will allow TA's to be loaded into these frame buffer areas. To mitigate this, we came up with this alternative: +----------------------------------+ <-- CFG_DRAM_BASE | | | Non-secure memory | | | +----------------------------------+ <-- CFG_TZDRAM_START | TEE core secure RAM (TEE_RAM) | +----------------------------------+ | Trusted Application RAM (TA_RAM) | +----------------------------------+ <-- CFG_POS_SEC_FB0_START (== CFG_TZDRAM_START + CFG_TZDRAM_SIZE) | Secure frame buffer 0 | +----------------------------------+ <-- CFG_POS_SEC_FB1_START | Secure frame buffer 1 | +----------------------------------+ <-- CFG_SHMEM_START | Non-secure static SHM | +----------------------------------+ <-- Top of DDR (CFG_SHMEM_START + CFG_SHMEM_SIZE) CFG_DDR_SIZE = 0x10000000 CFG_SHMEM_SIZE = 0x00200000 CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE)) CFG_SEC_FB_SIZE = 0x00096000 CFG_POS_SEC_FB1_START = ($(CFG_SHMEM_START) - $(CFG_SEC_FB_SIZE)) CFG_POS_SEC_FB0_START = ($(CFG_POS_SEC_FB1_START) - $(CFG_SEC_FB_SIZE)) CFG_TZDRAM_START = ($(CFG_DRAM_BASE) + 0x0e000000) CFG_TZDRAM_SIZE = ($(CFG_POS_SEC_FB0_START) - $(CFG_TZDRAM_START)) This solution puts the frame buffers outside the region CFG_TZDRAM_START:CFG_TZDRAM_SIZE so they no longer overlap with TA_RAM. However, when booting the system, op-tee panics: D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c2d4000..0x8c369fff pa 0x8fd6a000..0x8fdfffff size 0x00096000 (smallpg) D/TC:0 dump_mmap_table:732 type RAM_SEC va 0x8c36a000..0x8c3fffff pa 0x8fcd4000..0x8fd69fff size 0x00096000 (smallpg) ... D/TC:0 dump_mmap_table:732 type TA_RAM va 0x8c400000..0x8dfd3fff pa 0x8e100000..0x8fcd3fff size 0x01bd4000 (smallpg) ... E/TC:0 0 check_phys_mem_is_outside:332 Non-sec mem (0x8fcd4000:0x12c000) overlaps map (type 12 0x8fd6a000:0x96000) E/TC:0 0 Panic at core/arch/arm/mm/core_mmu.c:336 <check_phys_mem_is_outside> E/TC:0 0 TEE load address @ 0x8e000000 E/TC:0 0 Call stack: E/TC:0 0 0x8e005621 E/TC:0 0 0x8e01d397 E/TC:0 0 0x8e005aaf E/TC:0 0 0x8e004da7 E/TC:0 0 0x8e000174 In this situation, the memory area intended for the frame buffers (0x8fd6a000:0x96000) is now implicitly regarded as non-secure RAM, regardless of us registering it as MEM_AREA_RAM_SEC in main.c: register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB0_START, CFG_SEC_FB_SIZE); register_phys_mem(MEM_AREA_RAM_SEC, CFG_POS_SEC_FB1_START, CFG_SEC_FB_SIZE); Could you please confirm (or deny) that our first solution is the proper way to allocate these secure frame buffers and that they will not be overwritten by the process of loading TAs? If this is not the proper way, could you give us some pointers on how to do this? We do not feel comfortable allocating such large areas on the heap because of good taste and because we're not sure yet whether or not there are additional alignment requirement for these frame buffers. Perhaps something similar to the Linux slab-allocator is available? Thank you in advance for your help. With kind regards, Robert Deliën.

5 years, 5 months

1
0
0 0

[PATCH] optee: extend normal memory check to also write-through

by Andrey Zhizhikin

ARMv7 Architecture Reference Manual [1] section A3.5.5 details Normal memory type, together with cacheability attributes that could be applied to memory regions defined as "Normal memory". Section B2.1.2 of the Architecture Reference Manual [1] also provides details regarding the Memory attributes that could be assigned to particular memory regions, which includes the descrption of cacheability attributes and cache allocation hints. Memory type and cacheability attributes forms 2 separate definitions, where cacheability attributes defines a mechanism of coherency control rather than the type of memory itself. In other words: Normal memory type can be configured with several combination of cacheability attributes, namely: - Write-Through (WT) - Write-Back (WB) followed by cache allocation hint: - Write-Allocate - No Write-Allocate (also known as Read-Allocate) Those types are mapped in the kernel to corresponding macros: - Write-Through: L_PTE_MT_WRITETHROUGH - Write-Back Write-Allocate: L_PTE_MT_WRITEALLOC - Write-Back Read-Allocate: L_PTE_MT_WRITEBACK Current implementation of the op-tee driver takes in account only 2 last memory region types, while performing a check if the memory block is allocated as "Normal memory", leaving Write-Through allocations to be not considered. Extend verification mechanism to include also Normal memory regios, which are designated with Write-Through cacheability attributes. Link: [1]: https://developer.arm.com/documentation/ddi0406/cd Fixes: 853735e40424 ("optee: add writeback to valid memory type") Cc: stable(a)vger.kernel.org Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin(a)leica-geosystems.com> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index c981757ba0d4..8da27d02a2d6 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -535,7 +535,8 @@ static bool is_normal_memory(pgprot_t p) { #if defined(CONFIG_ARM) return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || - ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK) || + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITETHROUGH)); #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -- 2.17.1

5 years, 5 months

3
4
0 0

[GIT PULL] OP-TEE driver for v5.11

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which allows the OP-TEE driver to work with ARMv7 based single CPU systems. Thanks, Jens The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891: Linux 5.10-rc2 (2020-11-01 14:43:51 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-valid-memory-type-for-v5.11 for you to fetch changes up to 853735e404244f5496cdb6188c5ed9a0f9627ee6: optee: add writeback to valid memory type (2020-11-25 12:51:52 +0100) ---------------------------------------------------------------- Add writeback to valid OP-TEE shared memory types Allows OP-TEE to work with ARMv7 based single CPU systems by allowing writeback cache policy for shared memory. ---------------------------------------------------------------- Rui Miguel Silva (1): optee: add writeback to valid memory type drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

5 years, 5 months

2
2
0 0

[PATCH] optee: add writeback to valid memory type

by Rui Miguel Silva

Only in smp systems the cache policy is setup as write alloc, in single cpu systems the cache policy is set as writeback and it is normal memory, so, it should pass the is_normal_memory check in the share memory registration. Add the right condition to make it work in no smp systems. Fixes: cdbcf83d29c1 ("tee: optee: check type of registered shared memory") Signed-off-by: Rui Miguel Silva <rui.silva(a)linaro.org> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..c981757ba0d4 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -534,7 +534,8 @@ void optee_free_pages_list(void *list, size_t num_entries) static bool is_normal_memory(pgprot_t p) { #if defined(CONFIG_ARM) - return (pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC; + return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || + ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -- 2.29.2

5 years, 5 months

2
1
0 0

[PATCH] Properly check tee_shm buffer mmap offset

by gaoyusong

The memmap options in tee_shm_op_mmap were not being checked for all sets of possible crazy values. Fix this up by properly check tee_shm buffer offsets. Signed-off-by: gaoyusong <a869920004(a)163.com> --- drivers/tee/tee_shm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 827ac3d..3f762c8 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -75,6 +75,16 @@ static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) { struct tee_shm *shm = dmabuf->priv; size_t size = vma->vm_end - vma->vm_start; + unsigned long offset; + + /* Check dmabuffer mmap offset */ + if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT)) + return -EINVAL; + + offset = vma->vm_pgoff << PAGE_SHIFT; + + if (offset > shm->size || size > shm->size - offset) + return -EINVAL; /* Refuse sharing shared memory provided by application */ if (shm->flags & TEE_SHM_USER_MAPPED) -- 1.8.3.1

5 years, 5 months

2
1
0 0

[GIT PULL] AMDTEE driver fixes for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull these AMDTEE driver fixes which are needed when opening multiple contexts or file descriptors. Note that this isn't a usual Arm driver update. This targets x86/AMD instead, but is still part of the TEE subsystem. Thanks, Jens The following changes since commit bbf5c979011a099af5dc76498918ed7df445635b: Linux 5.9 (2020-10-11 14:15:50 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/amdtee-fixes-for-5.10 for you to fetch changes up to be353be27874f40837327d9a39e3ad2149ab66d3: tee: amdtee: synchronize access to shm list (2020-11-09 08:59:00 +0100) ---------------------------------------------------------------- AMD-TEE driver bug fixes AMD-TEE driver keeps track of shared memory buffers and their corresponding buffer id's in a global linked list. These buffers are used to share data between x86 and AMD Secure Processor. This pull request fixes issues related to maintaining mapped buffers in a shared linked list. ---------------------------------------------------------------- Rijo Thomas (2): tee: amdtee: fix memory leak due to reset of global shm list tee: amdtee: synchronize access to shm list drivers/tee/amdtee/amdtee_private.h | 8 ++++---- drivers/tee/amdtee/core.c | 26 +++++++++++++++++++------- 2 files changed, 23 insertions(+), 11 deletions(-)

5 years, 6 months

1
0
0 0

[PATCH 0/2] AMD-TEE driver bug fixes

by Rijo Thomas

AMD-TEE driver keeps track of shared memory buffers and their corresponding buffer id's in a global linked list. These buffers are used to share data between x86 and AMD Secure Processor. This patchset fixes issues related to maintaining mapped buffers in a shared linked list. Rijo Thomas (2): tee: amdtee: fix memory leak due to reset of global shm list tee: amdtee: synchronize access to shm list drivers/tee/amdtee/amdtee_private.h | 8 ++++---- drivers/tee/amdtee/core.c | 26 +++++++++++++++++++------- 2 files changed, 23 insertions(+), 11 deletions(-) -- 2.17.1

5 years, 6 months

2
3
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 6 months

1
0
0 0

[GIT PULL] OP-TEE use UUID API for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which allows to hide uuit_t internals from the OP-TEE driver. I know it's a bit late for v5.10, if it's too late please queue it for v5.11 instead. Thanks, Jens The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/optee-use-uuid-api-for-v5.10 for you to fetch changes up to 57222a1be27e06ecb81cc2f945e897814d5f461c: tee: optee: Use UUID API for exporting the UUID (2020-10-13 08:03:18 +0200) ---------------------------------------------------------------- Use UUID API to export the UUID Uses export_uuid() to export and uuid_t to an u8 array instead of depending on the internals of uuid_t. ---------------------------------------------------------------- Andy Shevchenko (1): tee: optee: Use UUID API for exporting the UUID drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

5 years, 6 months

2
1
0 0

[PATCH] tee: optee: Set a flag to avoid memory leaks

by Wang, Xiaolei

When an rpc message to release memory is not received, a memory leak will occur, which should be released unreferenced object 0xffff00006871b580 (size 128): comm "swapper/0", pid 1, jiffies 4294892673 (age 428.192s) hex dump (first 32 bytes): 80 b3 71 68 00 00 ff ff 00 e0 71 a8 00 00 00 00 ..qh......q..... 00 e0 71 68 00 00 ff ff 00 10 00 00 00 00 00 00 ..qh............ backtrace: [<00000000f0425299>] slab_post_alloc_hook+0x6c/0x338 [<000000004705f905>] kmem_cache_alloc+0x1d4/0x328 [<00000000773c66a0>] tee_shm_alloc+0x84/0x268 [<00000000ca052f98>] optee_handle_rpc+0x144/0x5a0 [<0000000015a8eebe>] optee_do_call_with_arg+0x14c/0x168 [<00000000d51ef0fd>] optee_open_session+0x12c/0x200 [<000000007146f51d>] tee_client_open_session+0x24/0x38 [<00000000ea2b35e7>] optee_enumerate_devices+0xa0/0x2c0 [<0000000068088775>] optee_probe+0x560/0x690 [<00000000ad1d997a>] platform_drv_probe+0x54/0xa8 [<00000000e11592d4>] really_probe+0x118/0x3e0 [<00000000dacd3142>] driver_probe_device+0x5c/0xc0 [<0000000077c13842>] device_driver_attach+0x74/0x80 [<00000000106ccc62>] __driver_attach+0x8c/0xd8 [<00000000e120c345>] bus_for_each_dev+0x7c/0xd8 [<00000000b79335f5>] driver_attach+0x24/0x30 Signed-off-by: Xiaolei Wang <xiaolei.wang(a)windriver.com<mailto:xiaolei.wang@windriver.com>> --- drivers/tee/optee/call.c | 7 ++++++- drivers/tee/optee/optee_private.h | 2 +- drivers/tee/optee/rpc.c | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..522c133b9d95 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -129,6 +129,7 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) struct optee_rpc_param param = { }; struct optee_call_ctx call_ctx = { }; u32 ret; + unsigned int flags = 0; param.a0 = OPTEE_SMC_CALL_WITH_ARG; reg_pair_from_64(&param.a1, &param.a2, parg); @@ -153,9 +154,13 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) param.a1 = res.a1; param.a2 = res.a2; param.a3 = res.a3; - optee_handle_rpc(ctx, &param, &call_ctx); + optee_handle_rpc(ctx, &param, &call_ctx, &flags); } else { ret = res.a0; + if (flags != 0x0) { + param.a0 = 2; + optee_handle_rpc(ctx, &param, &call_ctx, &flags); + } break; } } diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 8b71839a357e..1c1d62e21141 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -127,7 +127,7 @@ struct optee_call_ctx { }; void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, - struct optee_call_ctx *call_ctx); + struct optee_call_ctx *call_ctx, unsigned int *flags); void optee_rpc_finalize_call(struct optee_call_ctx *call_ctx); void optee_wait_queue_init(struct optee_wait_queue *wq); diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index b4ade54d1f28..4e76c87b61f4 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -396,7 +396,7 @@ static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee, * Result of RPC is written back into @param. */ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, - struct optee_call_ctx *call_ctx) + struct optee_call_ctx *call_ctx, unsigned int *flags) { struct tee_device *teedev = ctx->teedev; struct optee *optee = tee_get_drvdata(teedev); @@ -410,6 +410,7 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, reg_pair_from_64(&param->a1, &param->a2, pa); reg_pair_from_64(&param->a4, &param->a5, (unsigned long)shm); + *flags = 0x1; } else { param->a1 = 0; param->a2 = 0; @@ -420,6 +421,7 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, case OPTEE_SMC_RPC_FUNC_FREE: shm = reg_pair_to_ptr(param->a1, param->a2); tee_shm_free(shm); + *flags = 0x0; break; case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR: /* -- 2.25.1

5 years, 6 months

2
1
0 0

[PATCH v7 0/4] Introduce TEE based Trusted Keys support

by Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key. Also, this is an alternative in case platform doesn't possess a TPM device. This patch-set has been tested with OP-TEE based early TA which is already merged in upstream [1]. [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d… Changes in v7: 1. Added a trusted.source module parameter in order to enforce user's choice in case a particular platform posses both TPM and TEE. 2. Refine commit description for patch #1. Changes in v6: 1. Revert back to dynamic detection of trust source. 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. 3. Rebased to latest tpmdd/master. Changes in v5: 1. Drop dynamic detection of trust source and use compile time flags instead. 2. Rename trusted_common.c -> trusted_core.c. 3. Rename callback: cleanup() -> exit(). 4. Drop "tk" acronym. 5. Other misc. comments. 6. Added review tags for patch #3 and #4. Changes in v4: 1. Pushed independent TEE features separately: - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 2. Updated trusted-encrypted doc with TEE as a new trust source. 3. Rebased onto latest tpmdd/master. Changes in v3: 1. Update patch #2 to support registration of multiple kernel pages. 2. Incoporate dependency patch #4 in this patch-set: https://patchwork.kernel.org/patch/11091435/ Changes in v2: 1. Add reviewed-by tags for patch #1 and #2. 2. Incorporate comments from Jens for patch #3. 3. Switch to use generic trusted keys framework. Sumit Garg (4): KEYS: trusted: Add generic trusted keys framework KEYS: trusted: Introduce TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source MAINTAINERS: Add entry for TEE based Trusted Keys Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++--- MAINTAINERS | 8 + include/keys/trusted-type.h | 47 +++ include/keys/trusted_tee.h | 55 ++++ include/keys/trusted_tpm.h | 17 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 334 +++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 278 ++++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 336 ++++------------------ 9 files changed, 953 insertions(+), 327 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_core.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.7.4

5 years, 7 months

4
18
0 0

OP-TEE 3.11.0 has been released

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi, FYI, I have just finalized the OP-TEE 3.11.0 release (changelog [1]). Once again, many thanks to all of you who contributed to this release by submitting or reviewing code, or taking part in release testing [2]. [1] https://github.com/OP-TEE/optee_os/blob/3.11.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/c4def2a8262a Regards, -- Jerome

5 years, 7 months

1
0
0 0

[GIT PULL] TEE fix for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small fix which reenables the kernel login method in the kernel internal TEE client API. This fixes a problem introduced in v5.8. Thanks, Jens The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-fix-for-v5.10 for you to fetch changes up to 722939528a37aa0cb22d441e2045c0cf53e78fb0: tee: client UUID: Skip REE kernel login method as well (2020-10-13 08:42:11 +0200) ---------------------------------------------------------------- Reenable kernel login method for kernel TEE client API The kernel TEE login method was accidentally disabled previously when enabling a few other login methods, so fix that here. ---------------------------------------------------------------- Sumit Garg (1): tee: client UUID: Skip REE kernel login method as well drivers/tee/tee_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

5 years, 7 months

1
0
0 0

Re: [PATCH v1] firmware: tee_bnxt: Use UUID API for exporting the UUID

by Andy Shevchenko

On Thu, Jun 18, 2020 at 01:56:48PM +0300, Andy Shevchenko wrote: > On Wed, Apr 22, 2020 at 04:00:21PM +0300, Andy Shevchenko wrote: > > There is export_uuid() function which exports uuid_t to the u8 array. > > Use it instead of open coding variant. > > > > This allows to hide the uuid_t internals. > > Any comment on this? Guys, who is going to pick this up? > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > > --- > > drivers/firmware/broadcom/tee_bnxt_fw.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c b/drivers/firmware/broadcom/tee_bnxt_fw.c > > index ed10da5313e86..4cf0c2576037d 100644 > > --- a/drivers/firmware/broadcom/tee_bnxt_fw.c > > +++ b/drivers/firmware/broadcom/tee_bnxt_fw.c > > @@ -197,7 +197,7 @@ static int tee_bnxt_fw_probe(struct device *dev) > > return -ENODEV; > > > > /* Open session with Bnxt load Trusted App */ > > - memcpy(sess_arg.uuid, bnxt_device->id.uuid.b, TEE_IOCTL_UUID_LEN); > > + export_uuid(sess_arg.uuid, &bnxt_device->id.uuid); > > sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC; > > sess_arg.num_params = 0; > > -- With Best Regards, Andy Shevchenko

5 years, 7 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

5 years, 7 months

1
0
0 0

Preparing for OP-TEE 3.11.0

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE 3.11.0 is scheduled to be released on Friday, October 16th. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comment is https://github.com/OP-TEE/optee_os/pull/4101. As usual, I will create a release candidate tag one week before the release date for final testing. Thanks! Regards, -- Jerome

5 years, 7 months

2
1
0 0

[PATCH v3] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- Jens, do you have any advice on finding more reviewers for this? Changes in v3: - Remove free_app_id() and replace it with calls to kfree(). Changes in v2: - Rename some functions and variables to make them shorter. - Include linux/security.h unconditionally. - Restructure error handling in tee_session_calc_client_uuid(). drivers/tee/Kconfig | 29 ++++++++++ drivers/tee/tee_core.c | 126 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 147 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..3626ce0d9bd7 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,9 +7,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -21,7 +24,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +128,65 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + if (len < 0) + return ERR_PTR(len); + + fput(exe_file); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + fput(exe_file); + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +259,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -217,6 +281,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -227,10 +299,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -243,10 +311,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + kfree(app_id_data); break; default: @@ -254,7 +361,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.28.0

5 years, 7 months

1
0
0 0

[PATCH] tee: optee: replace might_sleep with cond_resched

by Rouven Czerwinski

On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force rescheduling, replace it with a resched check and cond_resched. Fixes the following stall: [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU [ 572.949275] rcu: 0-....: (2099 ticks this GP) idle=572/1/0x40000002 softirq=7412/7412 fqs=974 [ 572.957964] (t=2100 jiffies g=10393 q=21) [ 572.962054] NMI backtrace for cpu 0 [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1 [ 572.971188] Hardware name: STM32 (Device Tree Support) [ 572.976354] [<c011163c>] (unwind_backtrace) from [<c010b7f8>] (show_stack+0x10/0x14) [ 572.984080] [<c010b7f8>] (show_stack) from [<c0511e4c>] (dump_stack+0xc4/0xd8) [ 572.991300] [<c0511e4c>] (dump_stack) from [<c0519abc>] (nmi_cpu_backtrace+0x90/0xc4) [ 572.999130] [<c0519abc>] (nmi_cpu_backtrace) from [<c0519bdc>] (nmi_trigger_cpumask_backtrace+0xec/0x130) [ 573.008706] [<c0519bdc>] (nmi_trigger_cpumask_backtrace) from [<c01a5184>] (rcu_dump_cpu_stacks+0xe8/0x110) [ 573.018453] [<c01a5184>] (rcu_dump_cpu_stacks) from [<c01a4234>] (rcu_sched_clock_irq+0x7fc/0xa88) [ 573.027416] [<c01a4234>] (rcu_sched_clock_irq) from [<c01acdd0>] (update_process_times+0x30/0x8c) [ 573.036291] [<c01acdd0>] (update_process_times) from [<c01bfb90>] (tick_sched_timer+0x4c/0xa8) [ 573.044905] [<c01bfb90>] (tick_sched_timer) from [<c01adcc8>] (__hrtimer_run_queues+0x174/0x358) [ 573.053696] [<c01adcc8>] (__hrtimer_run_queues) from [<c01aea2c>] (hrtimer_interrupt+0x118/0x2bc) [ 573.062573] [<c01aea2c>] (hrtimer_interrupt) from [<c09ad664>] (arch_timer_handler_virt+0x28/0x30) [ 573.071536] [<c09ad664>] (arch_timer_handler_virt) from [<c0190f50>] (handle_percpu_devid_irq+0x8c/0x240) [ 573.081109] [<c0190f50>] (handle_percpu_devid_irq) from [<c018ab8c>] (generic_handle_irq+0x34/0x44) [ 573.090156] [<c018ab8c>] (generic_handle_irq) from [<c018b194>] (__handle_domain_irq+0x5c/0xb0) [ 573.098857] [<c018b194>] (__handle_domain_irq) from [<c052ac50>] (gic_handle_irq+0x4c/0x90) [ 573.107209] [<c052ac50>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x90) [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40) [ 573.119732] fce0: ffff0004 00000000 [ 573.127917] fd00: 00000000 00000000 00000000 00000000 00000000 00000000 d93493cc ffff0000 [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384 c01151f0 400d0013 ffffffff [ 573.144281] [<c0100b0c>] (__irq_svc) from [<c01151f0>] (__arm_smccc_smc+0x10/0x20) [ 573.151854] [<c01151f0>] (__arm_smccc_smc) from [<c09f3384>] (optee_smccc_smc+0x3c/0x44) [ 573.159948] [<c09f3384>] (optee_smccc_smc) from [<c09f4170>] (optee_do_call_with_arg+0xb8/0x154) [ 573.168735] [<c09f4170>] (optee_do_call_with_arg) from [<c09f4638>] (optee_invoke_func+0x110/0x190) [ 573.177786] [<c09f4638>] (optee_invoke_func) from [<c09f1ebc>] (tee_ioctl+0x10b8/0x11c0) [ 573.185879] [<c09f1ebc>] (tee_ioctl) from [<c029f62c>] (ksys_ioctl+0xe0/0xa4c) [ 573.193101] [<c029f62c>] (ksys_ioctl) from [<c0100060>] (ret_fast_syscall+0x0/0x54) [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0) [ 573.205803] ffa0: be926bf4 be926a78 00000003 8010a403 be926908 004e3cf8 [ 573.213987] ffc0: be926bf4 be926a78 00000000 00000036 be926908 be926918 be9269b0 bffdf0f8 [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8 seen on STM32 DK2. Signed-off-by: Rouven Czerwinski <r.czerwinski(a)pengutronix.de> --- drivers/tee/optee/call.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..83b73b1d52f0 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -8,6 +8,7 @@ #include <linux/errno.h> #include <linux/mm.h> #include <linux/slab.h> +#include <linux/sched.h> #include <linux/tee_drv.h> #include <linux/types.h> #include <linux/uaccess.h> @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) */ optee_cq_wait_for_completion(&optee->call_queue, &w); } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) { - might_sleep(); + if(need_resched()) + cond_resched(); param.a0 = res.a0; param.a1 = res.a1; param.a2 = res.a2; -- 2.28.0

5 years, 7 months

3
2
0 0

[PATCH v2] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- drivers/tee/Kconfig | 29 +++++++++ drivers/tee/tee_core.c | 133 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 154 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index 6488b66d69dd..cd8f02a3d488 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -10,6 +10,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 67186d00a52f..31fb244b59ed 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -16,9 +16,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -31,7 +34,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -136,6 +139,72 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + if (len < 0) + return ERR_PTR(len); + + fput(exe_file); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + fput(exe_file); + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + +#if defined(CONFIG_TEE_APPID_PATH) || defined(CONFIG_TEE_APPID_SECURITY) +static void free_app_id(void *data) +{ + kfree(data); +} +#endif /* CONFIG_TEE_APPID_PATH || CONFIG_TEE_APPID_SECURITY */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -208,6 +277,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -228,6 +299,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -238,10 +317,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -254,10 +329,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + free_app_id(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + free_app_id(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + free_app_id(app_id_data); break; default: @@ -265,7 +379,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.17.1

5 years, 7 months

2
2
0 0

Re: Linaro OP-TEE Contributions meeting Sept 2020

by Jérôme Forissier

Hi Joakim, On Tue, Sep 29, 2020 at 12:00 PM Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > Hi Jorge, > > On Tue, 29 Sep 2020 at 11:49, Jorge Ramirez <jorge(a)foundries.io> wrote: > > > Hi Joakim > > > > Shall we discuss how we want to extend the criptodriver API were > different > > algorithms can be taken from different ciphers? > > And maybe also how to communicate other than using the github frontend? I > > think this is useful in the case of relatively complex PR. > > > Sounds good to me, I'm adding that to the agenda. This concludes that there > _will_ be a LOC meeting tomorrow Wednesday 30th Sept @ 16.00 (UTC+2). > > Again, connection details etc can be found in the meeting notes document: > http://bit.ly/loc-notes Apologies for not joining, I had a calendar issue (my fault!). Since the date for the next release is confirmed and coming soon, I will create the release PR and send the notification email shortly. Thanks, -- Jerome

5 years, 7 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE