-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TinyCrypt deprecation - library's usage removal part 2 (bluetooth) #79931
Changes from all commits
690ab33
ee102cc
552c75f
861a322
a86fe28
6dc579a
36c93c4
59438c9
f70fc74
0692234
8b68b9e
b2d4d79
af0b2fd
29775c7
fad4c94
acbe7b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,9 +20,18 @@ static int entropy_bt_init(const struct device *dev) | |
static int entropy_bt_get_entropy(const struct device *dev, | ||
uint8_t *buffer, uint16_t length) | ||
{ | ||
if (!bt_is_ready()) { | ||
return -EAGAIN; | ||
} | ||
/* Do not wait for BT to be ready (i.e. bt_is_ready()) before issueing | ||
* the command. The reason is that when crypto is enabled and the PSA | ||
* Crypto API support is provided through Mbed TLS, random number generator | ||
* needs to be available since the very first call to psa_crypto_init() | ||
* which is usually done before BT is completely initialized. | ||
* On the other hand, in devices like the nrf5340, the crytographically | ||
* secure RNG is owned by the cpu_net, so the cpu_app needs to poll it | ||
* to get random data. Again, there is no need to wait for BT to be | ||
* completely initialized for this kind of support. Just try to send the | ||
* request through HCI. If the command fails for any reason, then | ||
* we return failure anyway. | ||
*/ | ||
Comment on lines
+23
to
+34
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As the return value could be different, we need API documentation change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right! I didn't thought about this because I was using this through the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added the documentation to the |
||
|
||
return bt_hci_le_rand(buffer, length); | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
# We need a random number generator to properly initialize the PSA Crypto core | ||
# implemented by Mbed TLS. The proper thing to do in this platform would be | ||
# to enable ENTROPY_GENERATOR, but this is not supported right now for the | ||
# following reasons: | ||
# - at device-tree level (nrf54l15_cpuapp.dtsi) the only RNG source available | ||
# is "zephyr,psa-crypto-rng" which means that TF-M is required in order for | ||
# this to work. Unfortunately TF-M is still not supported for this platform, yet. | ||
# - cpuapp does not have a direct access to the RNG without TF-M, so there's | ||
# no other way it can make use of it as of now. | ||
# | ||
# Since both options are not viable, we fall back to the test random generator | ||
# until further support is added to the platform. | ||
CONFIG_TEST_RANDOM_GENERATOR=y |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,2 @@ | ||
CONFIG_PM=y | ||
CONFIG_ENTROPY_GENERATOR=y |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,2 @@ | ||
CONFIG_PM=y | ||
CONFIG_ENTROPY_GENERATOR=y |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,7 +5,7 @@ CONFIG_ISR_STACK_SIZE=1024 | |
CONFIG_IDLE_STACK_SIZE=256 | ||
CONFIG_MAIN_STACK_SIZE=512 | ||
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512 | ||
CONFIG_HEAP_MEM_POOL_SIZE=4096 | ||
CONFIG_HEAP_MEM_POOL_SIZE=1024 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be reverted. 1024 is too small There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but since I just rebased after some dependency PRs were merged, I propose to keep this commit as-is and see if the CI is still OK, then remove it afterward. RAM usage in cpu_net has already shown to be a bit critical, so I suggest to change 1 thing at the time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This won't be caught by CI. It will only be triggered when running on-target on the nRF5340 I believe :) But would be caught by the PTS tests we can trigger There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it won't be caught by (auto)PTS... as we have overlay in bttester for nrf5340 netcore which set this to ...7k There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ahh scratch that, it loos like it uses just defaults from hci_ipc sample now There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, we just modified that :) |
||
CONFIG_CBPRINTF_REDUCED_INTEGRAL=y | ||
|
||
CONFIG_ISR_TABLES_LOCAL_DECLARATION=y | ||
|
@@ -143,3 +143,19 @@ CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y | |
|
||
# Ignore HCI ISO data Tx sequence numbers | ||
# CONFIG_BT_CTLR_ISOAL_PSN_IGNORE=y | ||
|
||
# The hci_ipc image has a quite high RAM usage so we need to carefully | ||
# tweak Mbed TLS parameters in order to build successfully: | ||
# - use CSPRNG source as random source for PSA. This removes | ||
# requiement for legacy Mbed TLS entropy+ctr-drbg modules, which | ||
# saves RAM and ROM; | ||
# - use ROM pre-computed tables for AES; | ||
# - reduce the number of key slots to 3 in the PSA core. This is not a | ||
# huge limitation since PSA crypto is only used for AES-CMAC in hci_ipc. | ||
CONFIG_MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG=y | ||
CONFIG_MBEDTLS_AES_ROM_TABLES=y | ||
CONFIG_MBEDTLS_PSA_KEY_SLOT_COUNT=3 | ||
|
||
# Reduce RAM footprint further otherwise the image won't fit in cpu_net. | ||
CONFIG_BT_CTLR_ADV_ISO_SET=1 | ||
CONFIG_BT_CTLR_ADV_ISO_STREAM_COUNT=2 |
This file was deleted.
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
CONFIG_ENTROPY_GENERATOR=y |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
&rng { | ||
status = "okay"; | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
# We need a random number generator to properly initialize the PSA Crypto core | ||
# implemented by Mbed TLS. The proper thing to do in this platform would be | ||
# to enable ENTROPY_GENERATOR, but this is not supported right now for the | ||
# following reasons: | ||
# - at device-tree level (nrf54l15_cpuapp.dtsi) the only RNG source available | ||
# is "zephyr,psa-crypto-rng" which means that TF-M is required in order for | ||
# this to work. Unfortunately TF-M is still not supported for this platform, yet. | ||
# - cpuapp does not have a direct access to the RNG without TF-M, so there's | ||
# no other way it can make use of it as of now. | ||
# | ||
# Since both options are not viable, we fall back to the test random generator | ||
# until further support is added to the platform. | ||
CONFIG_TEST_RANDOM_GENERATOR=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't think this belongs to here, the migration guide should be for things one would have to do to migrate, there's no instructions here, maybe it was meant to go in release notes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote it here because this was a change compared to the previous behavior. I mean, if the final user is already successfully using this driver then he won't notice any difference, but now they can use it also in other scenarios. I thought that
release-notes
was mostly for new features.Perhaps I misinterpreted the difference between
migration-guide
andrelease-notes
. Do you suggest to move it anyway?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah there's probably some space for interpretation but I think the migration guide should be for stuff where the user has to take an action, like change something on the application side. @kartben? Anyway I don't think it's super important. One thing you may mention though is that some bluetooth functionalities now depends on the
mbedtls
module rather thantinycrypt
, this is useful if anyone is running a project with aname-allowlist
filter project list.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, perhaps you're right. I mentioned something below for bt-mesh, but BT in general is affected by this, not only mesh. I will prepare a follow-up PR to add documentation