Make taskYIELD available to unprivileged tasks

[aggarg]

Description

This PR makes taskYIELD available to unprivileged tasks on ARMv8-M ports.

Test Steps

Tested on Cortex-M23 and Cortex-M33 platforms. Calling taskYIELD from an unprivileged task results in fault without these changes and, works normally after these changes.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#788

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (d442d79) 93.62% compared to head (a699cd2) 93.62%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #817   +/-   ##
=======================================
  Coverage   93.62%   93.62%           
=======================================
  Files           6        6           
  Lines        2508     2508           
  Branches      598      598           
=======================================
  Hits         2348     2348           
  Misses        107      107           
  Partials       53       53           

Flag	Coverage Δ
unittests	93.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[urutva]

@aggarg Changes looks good to me. However, using the SVC to raise privilege similar to Armv7-M implementation works in this scenario, I'm wondering would it be worth looking at implementing portYIELD similar to MPU_vTaskDelay. With this, we'll have unified FreeRTOS system calls for APIs with MPU wrappers and only FreeRTOS system calls can raise privilege. Any thoughts on this?

[aggarg]

The following happens when a system call executes:

1. Raise an SVC for system call enter - this copies the HW saved stack and params passed on the stack to the system call stack. It raises privileges and switches PSP to use system call stack.
2. Call the privileged only kernel API.
3. Raise an SVC for system call exit - this copies the HW saved stack to the task stack. It drops privileges and switches PSP to use task stack again.

This is done to ensure we do not execute kernel APIs which execute with elevated privilege on an unprivileged stack. This much complexity is not needed if the work is small and can be completed in the SVC handler itself (which happens to be case of yield).

Also, returning to Thread mode is necessary for executing kernel APIs primarily for two reasons - one, many of them block and two, they are somewhat larger than what you'd want to execute in Handler mode. Neither of those reasons apply to yield which is a very simple operation and can be completed in the SVC Handler itself. Therefore, I kept it in the SVC handler.

[urutva]

@aggarg Thanks for the detailed explanation.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication