Investigate potential for adding CI to mTower

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_PopulateTransientObject and __utee_from_attr

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_PopulateTransientObject and pass a large number of the parameter "attrCount"

Suggested description of the vulnerability for use in the CVE

Memory leak in TEE_PopulateTransientObject and __utee_from_attr functions in Samsung Electronics mTower v0.3.0(and earlier) allows a trusted application to trigger denial of service and information disclosure via invoking the function TEE_PopulateTransientObject with a large number of the parameter "attrCount".

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_PopulateTransientObject function takes a number "attrCount" and create an array "ua". This value is passed by TA, and TEE_PopulateTransientObject does not check its size. Then it is passed to __utee_from_attr. The __utee_from_attr function tries to copy data from "attrs" to "ua". The problem appears in the assignments in the for loop. If the attr_count is too large, "ua" will overlap the memory region of other TAs' (tampering data such as global variables, or causing TEE crash and triggers denial of service because of illegal address dereference).

Contact

[email protected]

To operate a Secure Boot, metadata of BL2 must be available to BL1 at system startup.
fwinfogen.c must generate a structure describing BL2, in a way similar to shown below.

const uint32_t g_InitialFWinfo[] =
{
  /* public key - 64-bytes (256-bits + 256-bits) */
  0x5b8695d1, 0xe183b68e, 0xa924c9b5, 0x7d006c3e,
  0xc59cef2e, 0x7553a8bf, 0xd6edba7e, 0xd61fc965,
  0xd26e436c, 0x6a302846, 0xabc1cb13, 0xb06b850e,
  0x691f3afe, 0x85ed36bc, 0x314d5e2f, 0xfb5b2b24,

  /* metadata data - includes Mode selection, F/W region and Extend info */
  0x00000001, 0x00000008, 0x10040000, 0x00010a48, // 0x00020000: NuBL32 F/W base
  0x0000000c, 0x20191219, 0x00001111, 0x22223333, // 0x20180824/0x00001111/0x22223333: Extend info

  /* FW hash - 32-bytes (256-bits) */
  0x8bba8d7b, 0x52788b97, 0x60a12a8a, 0xa827f204,
  0xef5db443, 0x6bed61ce, 0xadcefa21, 0x8ef9c55b,

  /* FwInfo signature - 64-bytes (256-bits R + 256-bits S) */
  0x9a11cc48, 0x1bcd859a, 0x39c8e943, 0x148cd93d,
  0x96290f3c, 0xeb84455c, 0x873e4706, 0x5f8f09c7,
  0x54619ff9, 0x30f52a30, 0x221e366f, 0x35c15536,
  0x8254b390, 0x6c598a09, 0x3c0e9ec7, 0x7da9e940,
};

asdf

Hi there,
Recently I'm trying to trace mTower in gdb, using OpenOCD as gdb server and Nu-link2 pro as debug dongle.
Here is how I start the experiment:

1. Complie the mTower on Ubuntu 20.04 and flash two .bin files on Windows10 using ICP programming tool via Nu-link2 pro debug dongle.
2. Connect the board (NuMaker-FPM-M2351) to Ubuntu 20.04 using Nu-link2 pro debug dongle as the bridge.
3. Start OpenOCD using the following command, then use gdb to connect the board in another terminal.

sudo ./src/openocd -f tcl/interface/nulink.cfg -f tcl/target/numicroM23.cfg

It just stuck here. Then I press Ctrl+C and check current info --- it seems to get stuck in a loop --- as shown in the following picture:

Here is the photo of hardware connection. The green LED of the development board keeps flashing when gdb sends command 'c' to keep the process running. The ICE LED and the red LED of the debug dongle are on. As to the four switches of the Nu-Link-Me ICE bridge, the TXD, RXD and VCOM are on and MSG is off.

It confuses me a lot that no output is given in gdb, which is expected to appear as following ( simply connect the board to XShell using the Nu-Link-Me ICE bridge with the same switch status) :

Thus,
How to use gdb to trace mTower process normally?
What else should I do?

Looking forward to your help.

Describe the bug
There are several conflicting license types used in mTower components.

To Reproduce

Expected behavior
Licenses should be non-conflicting

Additional context
Apache license should be applied to mTower overall; however, some files will remain under BSD license maintaining the rights of third parties.

Hi there,
We are currently testing mTower v0.3.0 on GitHub and have encountered a perplexing bug. During our testing, we discovered that an external structure can be modified within the printf system call.

Before debugging this issue, we added a printf function to the tee/lib/libutils/isoc/include/sys/queue.h file. The added code is as follows:

#define TAILQ_REMOVE(head, elm, field) do {             \
    QUEUEDEBUG_TAILQ_PREREMOVE((head), (elm), field)        \
    printf("elm->field is at %p and is %p\n",&elm->field,elm->field); \
    QUEUEDEBUG_TAILQ_OP((elm), field)               \
    if (((elm)->field.tqe_next) != NULL)                \
        (elm)->field.tqe_next->field.tqe_prev =         \
            (elm)->field.tqe_prev;              \
    else                                \
        (head)->tqh_last = (elm)->field.tqe_prev;       \
    *(elm)->field.tqe_prev = (elm)->field.tqe_next;         \
    QUEUEDEBUG_TAILQ_POSTREMOVE((elm), field);          \
} while (/* CONSTCOND */0)

We have documented our debugging process in detail in this Google Doc.

We are unsure if this issue is caused by the code provided by the project or by a base library. Therefore, we would appreciate your insights into the issue. If there are any details we have overlooked or missed, please let us know. We would be grateful for any guidance you can offer.

Best regards,
SyzTrust

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_DigestDoFinal
Attack vector(s)

To exploit the vulnerability, invoke the function TEE_DigestDoFinal and pass an excessive size value of "chunkLen".

Suggested description of the vulnerability for use in the CVE

Buffer Access with Incorrect Length Value vulnerablity in TEE_DigestDoFinal function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_DigestDoFinal with a excessive size value of "chunkLen".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_DigestDoFinal function takes an argument "chunkLen". This value is passed by TA, and TEE_DigestDoFinal does not check whether it is the size of "chunk" or not. With an excessively large value, executing the statement "res = utee_hash_final(operation->state, chunk, chunkLen, hash, &hl);" later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_DigestUpdate
Attack vector(s)

To exploit the vulnerability, invoke the function TEE_DigestUpdate and pass an excessive size value of "chunkSize".

Suggested description of the vulnerability for use in the CVE

Buffer Access with Incorrect Length Value vulnerability in TEE_DigestUpdate function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_DigestUpdate with an excessive size value of "chunkSize".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_DigestUpdate function takes an argument "chunkSize". This value is passed by TA, and TEE_DigestUpdate does not check whether it is equal to the size of "chunk" or not. With an excessive large value, executing the statement "memcpy(md-> state_var .buf + md-> state_var.curlen, in, (size_t)n);" later may crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Describe the bug
Need to create a specific, easy to follow guide on creating mTower-based secure application.

Expected behavior
A document must be present containing the said guide.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Keys for signing and signature verification must be generated by some procedure

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Affected components：

affected source code file: /tee/lib/libutee/tee_api.c, affected functions: TEE_Malloc

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_Malloc and pass a large number to the parameter "len".

Suggested description of the vulnerability for use in the CVE

Memory Allocation with Excessive Size Value vulnerablity in TEE_Malloc function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_Malloc with an excessive number of the parameter "len".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_Malloc does not check the size of chunk to malloc. Executing the statement "tee_user_mem_alloc" with an excessive size value on a real IoT hardware (such as Numaker-PFM-M2351) will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Contact

[email protected]

currently mTower use device related definitions which will lead to build fail when porting new device, and that's not good for a common function.

Currently, start address for Normal World (CONFIG_START_ADDRESS_BL33) is hardcoded. It should be set via configuration tool.
A configuration variable (e.g., CONFIG_START_ADDRESS_BL33) should be set and made available via Kconfig.

Affected components：

affected source code file: /tee/tee/tee_svc_cryp.c, affected functions: utee_cryp_obj_alloc
affected source code file: /tee/tee/tee_obj.c, affected functions: tee_obj_alloc and tee_obj_free

Attack vector(s)

One way to exploit the vulnerability, invoking the function TEE_AllocateOperation and TEE_Realloc with a large size to disturb the heap layout, and invoke TEE_AllocateOperation again.

Suggested description of the vulnerability for use in the CVE

Improper Input Validation vulnerablity in the function tee_obj_free in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_AllocateOperation with a disturbed heap layout.

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

As shown in POC, the calloc function in tee_obj_alloc does not return a buffer with all bits zero as expected when the heap layout was disturbed in mTower on a real IoT hardware (such as Numaker-PFM-M2351). Executing the statement free(o->attr) then will free an invalid pointer, which will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

PoC

poc_14.zip

THANK YOU FOR CONTRIBUTIONS IN MTOWER TEE OS!

Affected components

affected source code file: tools/fwinfogen.c

Attack vector(s)

Lacking a check for the return value of EC_KEY_set_public_key_affine_coordinates.
EC_KEY_set_public_key_affine_coordinates() returns 1 on success or 0 on error.

Suggested description of the vulnerability for use in the CVE

DoS vulnerability in sign_pFwInfo() function in Samsung Electronics mTower v0.3.0 (and earlier) due to a missing check on the return value of EC_KEY_set_public_key_affine_coordinates.

Discoverer(s)/Credits

UVScan

Reference(s)

https://www.openssl.org/docs/manmaster/man3/EC_KEY_set_public_key_affine_coordinates.html

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Affected components：

affected source code file: /tee/lib/libutee/tee_api.c, affected functions: TEE_Realloc

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_Realloc and pass a large number to the parameter "len".

Suggested description of the vulnerability for use in the CVE

Memory Allocation with Excessive Size Value vulnerablity in TEE_Realloc function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_Realloc with an excessive number of the parameter "len".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The function TEE_Realloc does not check the size of chunk to realloc. Executing the statement "tee_user_mem_realloc" with an excessive size value on a real IoT hardware (such as Numaker-PFM-M2351) will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

THANK YOU FOR CONTRIBUTIONS IN MTOWER TEE OS!

Hi there,
Recently, we found several untrusted pointer dereference bugs in the following functions:

1. TEE_MACComputeFinal
2. TEE_SetOperationKey2
3. TEE_MACUpdate
4. TEE_GetOperationInfoMultiple
5. TEE_AEEncryptFinal, TEE_MACInit
6. TEE_SetOperationKey
7. TEE_ResetOperation
8. TEE_DigestUpdate
9. TEE_AEDecryptFinal
10. TEE_CipherInit
11. TEE_FreeOperation
12. TEE_DigestDoFinal
13. TEE_AllocateOperation
14. TEE_FreeTransientObject
15. TEE_AEUpdate
16. TEE_ResetOperation

Here we use " function name " to present any of the above functions.

Affected product(s)/code base

mTower m2351 v0.4.0

Attack vector(s)

To exploit the vulnerability, invoke the function " function name " and pass an invalid pointer to the first parameter (TEE_OperationHandler).

Suggested description of the vulnerability for use in the CVE

Untrusted pointer dereference vulnerability in the" function name " function in Tsinglink Cloud TinyTEE M2351 v3.0.1 allows a trusted application to trigger a Denial of Service (DoS) via invoking the function " function name " with an invalid pointer of the first parameter, that is, TEE_OperationHandle.

Discoverer(s)/Credits

SyzTrust

Additional context
The " function name " function does not check whether the first parameter is in trusted space or not. When invoking this function and passing an invalid pointer, it will dereference the address and crash the trusted execution environment kernel, resulting in a Denial of Service (DoS).

Our suggested solution is to: add a handle list to record the handles that are allocated and returned by TEE_AlloacateOperation() and add the check on the TEE_OperationHandle to see if they are on the handle list. Once the TEE_OperationHandle is released, then delete the handle in the handle list.
Or, when trying to dereference any pointer in mTower, add a check to see if its address is in the legal memory region. For instance, the Linux kernel always checks if the userspace pointer is valid.

static inline void __chk_user_ptr(const volatile void *p, size_t siez){
    assert(p >= __user_addr_min && p + size <= __user_addr_max);
}

Looking forward to your reply!

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_GetObjectInfo1

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_GetObjectInfo1and pass a NULL pointer to the parameter "object".

Suggested description of the vulnerability for use in the CVE

Null pointer dereference vulnerablity in TEE_GetObjectInfo1 function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_GetObjectInfo1 with a Null pointer of the parameter "object".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_GetObjectInfo1 function takes a pointer "object". This value is passed by TA, and TEE_GetObjectInfo1 does not check whether it is a null pointer or not. Executing the statement "res = utee_cryp_obj_get_info((unsigned long)object, objectInfo)" which calls tee_svc_copy_to_user function later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Contact

[email protected]

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_AllocateTransientObject

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_AllocateTransientObject and pass a NULL pointer to the parameter "object".

Suggested description of the vulnerability for use in the CVE

Null pointer dereference vulnerablity in TEE_AllocateTransientObject function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_AllocateTransientObject with a Null pointer of the parameter "object".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_AllocateTransientObject function takes a pointer "object". This value is passed by TA, and TEE_AllocateTransientObject does not check whether it is a null pointer or not. Executing the statement "*object = (TEE_ObjectHandle)(uintptr_t)obj;" later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Contact

[email protected]

Need to provide error handling in key generation (invalid input, OOM, etc.)

mTower configuration options part of mtower_functionality_description.md file needs to be filled.

Affected components

affected source code file: tools/fwinfogen.c

Attack vector(s)

Lacking a check for the return value of EC_KEY_set_private_key.
EC_KEY_set_private_key() returns 1 on success or 0 on error except when the priv_key argument is NULL, in that case it returns 0, for legacy compatibility, and should not be treated as an error.

Suggested description of the vulnerability for use in the CVE

DoS vulnerability in sign_pFwInfo() function in Samsung Electronics mTower v0.3.0 (and earlier) due to a missing check on the return value of EC_KEY_set_private_key.

Discoverer(s)/Credits

UVScan

Reference(s)

https://www.openssl.org/docs/manmaster/man3/EC_KEY_set_private_key.html

Vulnerability type
Buffer overflow

Affected components
affected source code file: tee/lib/libutee/tee_api.c
affected functions: TEE_MemMove

Attack vector(s)
To exploit the vulnerability, invoke the function "TEE_MemMove" and pass a large number of "size" which is larger than the size of "dest".

Suggested description of the vulnerability for use in the CVE
Buffer overflow vulnerability in "TEE_MemMove" function in mTower v0.4.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) if "dest" is filled with more bytes than its capacity.

Discoverer(s)/Credits
SyzTrust

Reference(s)

Additional information
The "TEE_MemMove" function does not check the capacity of "dest" before executing "memmove(dest, src, size)". Unlike what the function "memmove" does in C, when too many bytes copied to "dest", the real IoT hardware (such as Numaker-PFM-M2351) will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Affected components

affected source code file: tools/ecdsa_keygen.c

Attack vector(s)

Lacking a check for the return value of EVP_CIPHER_CTX_new.
EVP_CIPHER_CTX_new() returns a pointer to a newly created EVP_CIPHER_CTX for success and NULL for failure.

Suggested description of the vulnerability for use in the CVE

Null pointer dereference vulnerability in aes256_encrypt() function in Samsung Electronics mTower v0.3.0 (and earlier) due to a missing check on the return value of EVP_CIPHER_CTX_new.

Discoverer(s)/Credits

UVScan

Reference(s)

https://www.openssl.org/docs/manmaster/man3/EVP_CIPHER_CTX_new.html

Data structures involved in TrustBoot sequence lack any description.

Structures themselves are taken from Nuvoton BSP (SecurityBootDemo project) and are compatible with BL1. Data can be taken from AN_0024_M2351_Trusted_Boot_EN_Rev1.00.pdf

Describe the bug
mTower needs concise installation instructions.

Describe the bug
mTower needs a guide on porting it to other H/W platforms.

Describe the bug
Author list in article should reflect actual contribution order in project

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_MACCompareFinal

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_MACCompareFinal and pass a NULL pointer to the parameter "operation".

Suggested description of the vulnerability for use in the CVE

Null pointer dereference vulnerablity in TEE_MACCompareFinal function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_MACCompareFinal with a Null pointer of the parameter "operation".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_MACCompareFinal function takes a pointer "operation". This value is passed by TA, and TEE_MACCompareFinal does not check whether it is a null pointer or not. Executing the statement "if (operation->info.operationClass != TEE_OPERATION_MAC)" later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

THANK YOU FOR CONTRIBUTIONS IN MTOWER TEE OS!

Buffer Access with Incorrect Length Value in the function TEE_MACUpdate

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_MACUpdate

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_MACUpdate and pass an excessive size value of "chunkSize".

Suggested description of the vulnerability for use in the CVE

Buffer Access with Incorrect Length Value vulnerablity in TEE_MACUpdate function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_MACUpdate with a excessive size value of "chunkSize".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_MACUpdate function takes an argument "chunkSize". This value is passed by TA, and TEE_MACUpdate does not check whether it is equal to the size of "chunk" or not. With an excessive large value, executing the statement "memcpy(md-> state_var .buf + md-> state_var.curlen, in, (size_t)n);" later may crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Buffer Access with Incorrect Length Value in the function TEE_MACComputeFinal

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_MACComputeFinal

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_MACComputeFinal and pass an excessive size value of "messageLen".

Suggested description of the vulnerability for use in the CVE

Buffer Access with Incorrect Length Value vulnerablity in TEE_MACComputeFinal function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_MACComputeFinal with a excessive size value of "messageLen".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_MACComputeFinal function takes an argument "messageLen". This value is passed by TA, and TEE_MACComputeFinal does not check whether it is the size of "message" or not. With an excessive large value, executing the statement "res = utee_cipher_update(operation->state, srcData, srcLen, destData, &dl);" later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

Buffer Access with Incorrect Length Value in the function TEE_CipherUpdate

Affected components：

affected source code file: /tee/lib/libutee/tee_api_objects.c, affected functions: TEE_CipherUpdate

Attack vector(s)

To exploit the vulnerability, invoke the function TEE_CipherUpdate and pass an excessive size value of "srcLen".

Suggested description of the vulnerability for use in the CVE

Buffer Access with Incorrect Length Value vulnerablity in TEE_CipherUpdate function in Samsung Electronics mTower v0.3.0 (and earlier) allows a trusted application to trigger a Denial of Service (DoS) via invoking the function TEE_CipherUpdate with a excessive size value of "srcLen".

Discoverer(s)/Credits

SyzTrust

Reference(s)

https://github.com/Samsung/mTower

Additional information

The TEE_CipherUpdate function takes an argument "srcLen". This value is passed by TA, and TEE_CipherUpdate does not check whether it is the size of "srcData" or not. With an excessive large value, executing the statement "res = utee_hash_final(operation->state, message, messageLen, mac, &ml);" later will crash the trusted execution environment kernel and cause a Denial of Service (DoS).

THANK YOU FOR CONTRIBUTIONS IN MTOWER TEE OS!

Describe the bug
There's no test suite to demonstrate that GP TEE API implementation in mTower operates as it should.

Expected behavior
A test suite must illustrate operation of standard GP TEE API calls and their usage.

mTower

• Platform: nuvoton NuMaker-PFM 2351,
• version: v0.1
• Toolchain: GNU GCC

Need to make a viable way to flash device from Linux

Describe the bug
Documentation on TEE and is difficult to access in online sources. Also, reference list in article is to be improved.

Expected behavior
Will move as much of TEE documentation as possible directly into repository; will improve reference list.

It is unclear how binary image size is determined. Both Normal World and Secure World images must have clear calculation methods for image sizes.

+-----------------------------------------------------------------------+
| Secure image                                                          |
+-----------------------------------------------------------------------+
| Name            | Start addr | End addr   | Size      | File name     |
+-----------------------------------------------------------------------+
| Boot loader 2   | 0x00000000 | 0x0000b934 | 47412	| bl2.bin       |
| Secure handler  | 0x00010000 | 0x00028d3c | 101692	| bl32.bin      |
| Metadata info   | start addr | end addr   | size      | *auto gen*    |
+-----------------------------------------------------------------------+
| mtower_s        | 0x00000000 | 0x000380c0 | 229568	| mtower_s.bin  |
+-----------------------------------------------------------------------+
+-----------------------------------------------------------------------+
| Non-Secure image                                                      |
+-----------------------------------------------------------------------+
| Name            | Start addr | End addr   | Size      | File name     |
+-----------------------------------------------------------------------+
| FreeRTOS        | 0x10040000 | 0x10050a48 | 68168	| bl33.bin      |
+-----------------------------------------------------------------------+
| mtower_ns       | 0x10040000 | 0x100780c0 | 229568	| mtower_ns.bin |
| Metadata info   | start addr | end addr   | size      | *auto gen*    |
+-----------------------------------------------------------------------+