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
secure_services: Lock scheduler before calling secure services. #2519
Conversation
If zephyrproject-rtos/zephyr#26414 goes through, this PR should be changed to accommodate |
b6121ba
to
1b0f329
Compare
Some checks failed. Please fix and resubmit. checkpatch issues
Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
9578a3a
to
96b306a
Compare
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 would believe that the scheduler lock needs to happen before the secure call (at least this is how I described the proposed solution in the respective ticket). Otherwise we do not completely get rid of race conditions. [Might be missing something so let's discuss.]
It does happen before the secure call. The _nsc functions are the entry functions. |
Ok, thanks, I saw it now. So the patch should be functionally fine, however I think it would be better to embed the cooperative scheduling enforcement in the way the Secure calls are defined. So you would not need to duplicate the kernel locking in every secure service call. And that patch could actually be sent upstream directly! |
96b306a
to
3099808
Compare
3099808
to
1ceeedb
Compare
1ceeedb
to
72c3fb5
Compare
72c3fb5
to
22d3fb8
Compare
This work was merged upstream in zephyrproject-rtos/zephyr#27831 and should be part of v2.4.0. I believe @oyvindronningstad has updated the current PR to take the upstream changes into account. |
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.
Thanks, this fixed the issue I was seeing when calling sys_rand32_get
.
I wonder if it would be better to infix _ncs_
instead e.g. spm_ncs_foo
, no strong opinion though.
nit: can you remove the punctuation from the commit title
subsys/spm/secure_services_ns.c
Outdated
int spm_prevalidate_b1_upgrade_nsc(uint32_t dst_addr, uint32_t src_addr); | ||
void spm_busy_wait_nsc(uint32_t busy_wait_us); | ||
|
||
TZ_THREAD_SAFE_NONSECURE_ENTRY_FUNC(spm_request_system_reboot, |
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 guess that the commit message was composed before this functionality was available in zephyr, so you should check that it is up to date.
call k_sched_lock before and k_sched_unlock after.
Rename the services from spm_foo() to spm_foo_nsc() and call
spm_foo_nsc() from spm_foo() along with k_sched_*()
There is no mention of k_sched
in this PR since it is all handled in the TZ macros.
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.
and by the way, you should elaborate here why THREAD_SAFE is needed (maybe some simple inline comments above the definitions)
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.
Reworded the commit message. I didn't add anything about thread safety here, but I added docs elsewhere.
config SPM_SERVICE_BUSY_WAIT | ||
bool "Busy wait in secure mode (debug function)" | ||
default y | ||
help |
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.
Could it depend on ZTEST so that its not visible for customers when running menuconfig on a normal project?
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.
Yes this is an option. (or TEST)
How about samples, where we would like to have this set by default as well?
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.
Sadly, this config (in SPM) cannot depend on a config in the app.
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.
But what if we modify the build system to pass "CONFIG_ZTEST" to any child image? In my opinion that is a reasonable feature. If you agree we can create a task and add it to the backlog.
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 spent a bit of time thinking about this yesterday. I had a similar thought. We have the option of passing -Dspm_CONFIG_TEST=y
-style Kconfig overrides from app to spm, but it's quite blunt, and means that those configs will be ignored if set with e.g. ninja spm_menuconfig
.
I also considered just doing it with the SPM_SERVICE configs since they anyway have particular requirements about being in sync across app and spm. Doing this would solve another problem as well, which I fix in #2710, but I like this solution better.
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.
The SPM_SERVICE_* configs are now passed from app to spm
@@ -0,0 +1,4 @@ | |||
tests: | |||
spm.secure_services.thread_swap: | |||
platform_allow: nrf9160dk_nrf9160ns nrf5340pdk_nrf5340_cpuappns |
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.
platform_allow: nrf9160dk_nrf9160ns nrf5340pdk_nrf5340_cpuappns | |
platform_allow: nrf9160dk_nrf9160ns nrf5340pdk_nrf5340_cpuappns nrf5340dk_nrf5340_cpuappns |
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.
Not really sure if this is needed, just check what is in the other tests.
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.
Looks like nrf5340dk_nrf5340_cpuappns is not used in any testcase.yaml or sample.yaml files yet.
22d3fb8
to
8ed74a7
Compare
8ed74a7
to
22d3fb8
Compare
@oyvindronningstad retriggered CI by forced push: 22d3fb81a24121f42793dba6fa84cf54fe3688de --> 22d3fb81a24121f42793dba6fa84cf54fe3688de |
22d3fb8
to
10e6282
Compare
Rebased on latest master and force pushed from 22d3fb8 to 10e6282 to try and fix CI. |
Hmm, look like there's legit failures in CI
|
10e6282
to
4527812
Compare
I couldn't reproduce this locally with samples, so the test might be misconfigured. Will look more into later. |
dc9d60c
to
15af30d
Compare
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.
Some small nits, and one possible flaw but not necessarily blocking for merging.
list(FILTER VARIABLES_CACHED INCLUDE REGEX ${regex}) | ||
|
||
foreach(var_name ${VARIABLES} ${VARIABLES_CACHED}) | ||
set(spm_${var_name} ${${var_name}}) |
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.
So, if user did: -Dspm_CONFIG_SPM_SERVICE<something>=<value>
that will be lost and overwritten with the value of CONFIG_SPM_SERVICE<something>
.
Sounds like a flaw.
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.
In the case of these configs, any mismatch in configuration between SPM and app is an error, so in this case, it's "desired". Ideally, there should be a way to prevent setting the config in SPM, but I opted to just mention it in the help text.
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.
accepted.
Probably we should warn the user then, in case he has already defined spm_CONFIG_SPM_SERVICE<something>
before overwriting the value.
But that can be done as enhancement.
15af30d
to
23833ba
Compare
Thanks. This is now used via concatenation though, so infix is not really a convenient alternative.
Thanks, done |
Rename the services from spm_foo() to spm_foo_nsc() and create new wrapper functions spm_foo() k_sched_*) using TZ_THREAD_SAFE_NONSECURE_ENTRY_FUNC(). Ref: NCSIDB-108 Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
The service busy waits in secure mode, so we can test e.g. thread swapping between secure and nonsecure. Ref: NCSIDB-108 Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This test verifies that secure services can be safely interrupted by a thread swap that also calls a secure service. Ref: NCSIDB-108 Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This is now the preferred way, to keep the configs in sync. Ref: NCSIDB-108 Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
23833ba
to
9e39d93
Compare
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.
LGTM
Stale, comments himself afterwards that the reason he NACKed was a misunderstanding.
call k_sched_lock before and k_sched_unlock after.
Rename the services from spm_foo() to spm_foo_nsc() and call
spm_foo_nsc() from spm_foo() along with k_sched_*()
Ref: NCSIDB-108
Signed-off-by: Øyvind Rønningstad oyvind.ronningstad@nordicsemi.no