Can these global or RW symbol be removed? #267

Closed
opened 2019-09-18 22:02:20 -05:00 by kenlsoft · 5 comments
kenlsoft commented 2019-09-18 22:02:20 -05:00 (Migrated from github.com)

Hi,
We are planning to put mbed-crypto into some read-only area, but we found there are some RW data available, which makes the putting harder:
0x38006708 0x00000008 Data RW 2856 .data.ecp_mod_p192k1.Rp (ecp_curves.o)
0x38006710 0x00000008 Data RW 2857 .data.ecp_mod_p224k1.Rp (ecp_curves.o)
0x38006718 0x00000008 Data RW 2858 .data.ecp_mod_p256k1.Rp (ecp_curves.o)
0x38006720 0x00000004 Data RW 2855 .data.ecp_mpi_set1.one (ecp_curves.o)
0x3800894d 0x0000000c Zero RW 2757 .bss.ecp_supported_grp_id (ecp.o)
0x38008960 0x000003c8 Zero RW 1909 .bss.global_data (psa_crypto.o)
0x38008d28 0x00000484 Zero RW 3192 .bss.global_data (psa_crypto_slot_management.o)
0x380091ac 0x00000080 Zero RW 1676 .bss.handle_owner (crypto_key.o)

Is it possible to change these part to make a read-only library of mbed-crypto? I know there are some others in memory and aes but there are configurable so no worry on that part.

Hi, We are planning to put mbed-crypto into some read-only area, but we found there are some RW data available, which makes the putting harder: 0x38006708 0x00000008 Data RW 2856 .data.ecp_mod_p192k1.Rp (ecp_curves.o) 0x38006710 0x00000008 Data RW 2857 .data.ecp_mod_p224k1.Rp (ecp_curves.o) 0x38006718 0x00000008 Data RW 2858 .data.ecp_mod_p256k1.Rp (ecp_curves.o) 0x38006720 0x00000004 Data RW 2855 .data.ecp_mpi_set1.one (ecp_curves.o) 0x3800894d 0x0000000c Zero RW 2757 .bss.ecp_supported_grp_id (ecp.o) 0x38008960 0x000003c8 Zero RW 1909 .bss.global_data (psa_crypto.o) 0x38008d28 0x00000484 Zero RW 3192 .bss.global_data (psa_crypto_slot_management.o) 0x380091ac 0x00000080 Zero RW 1676 .bss.handle_owner (crypto_key.o) Is it possible to change these part to make a read-only library of mbed-crypto? I know there are some others in memory and aes but there are configurable so no worry on that part.
gilles-peskine-arm commented 2019-09-19 03:31:21 -05:00 (Migrated from github.com)

For the ECP modules (ecp_curves and ecp), there are data structures that are calculated on the first use of each curve. I recall discussions about trading slightly larger code size for getting rid of these global variables and saving a small amount of time during application start-up. I think it's possible but it may require an API change.

For psa_crypto and psa_crypto_slot_management, the API does not have a context pointer passed around to every function. The library needs to keep track of some global data between calls, including key material and a key handle table. I don't think you can implement the PSA crypto API without global data. This was an explicit trade-off during the API design: keep the API simple, and make the implementer do the hard work. We thought that global data is annoying on some platforms because it requires instructions to the linker, but it's possible pretty much everywhere. On PSA platforms, global variables must work. What platform are you building for?

crypto_key does not exist in Mbed Crypto.

For the ECP modules (`ecp_curves` and `ecp`), there are data structures that are calculated on the first use of each curve. I recall discussions about trading slightly larger code size for getting rid of these global variables and saving a small amount of time during application start-up. I think it's possible but it may require an API change. For `psa_crypto` and `psa_crypto_slot_management`, the API does not have a context pointer passed around to every function. The library needs to keep track of some global data between calls, including key material and a key handle table. I don't think you can implement the PSA crypto API without global data. This was an explicit trade-off during the API design: keep the API simple, and make the implementer do the hard work. We thought that global data is annoying on some platforms because it requires instructions to the linker, but it's _possible_ pretty much everywhere. On PSA platforms, global variables must work. What platform are you building for? `crypto_key` does not exist in Mbed Crypto.
kenlsoft commented 2019-09-19 03:51:43 -05:00 (Migrated from github.com)

Thanks for your reply. The intention is to put mbed-crypto into some shared area. About the context, maybe the memory could be provided by the caller, or use some malloc() things?

Thanks for your reply. The intention is to put mbed-crypto into some shared area. About the context, maybe the memory could be provided by the caller, or use some malloc() things?
gilles-peskine-arm commented 2019-09-19 03:58:21 -05:00 (Migrated from github.com)

We could change the library to support using a malloc'ed block instead of a global array (and indeed we will at some point to make the array size configurable at runtime). But you'd still need a global variable to store the pointer to this allocated block.

We could change the library to support using a malloc'ed block instead of a global array (and indeed we will at some point to make the array size configurable at runtime). But you'd still need a global variable to store the pointer to this allocated block.
ciarmcom commented 2019-09-19 07:17:48 -05:00 (Migrated from github.com)

Internal Jira reference: https://jira.arm.com/browse/IOTCRYPT-921

*Internal Jira reference: https://jira.arm.com/browse/IOTCRYPT-921*
Patater commented 2019-10-11 07:03:33 -05:00 (Migrated from github.com)

Closing as wontfix, as we'll always need some global RW data with the current library design.

Closing as wontfix, as we'll always need some global RW data with the current library design.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-ARMmbed/mbed-crypto#267
No description provided.