Skip to content
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

Next round of changes to the switcher #358

Merged
merged 12 commits into from
Dec 10, 2024

Conversation

nwf
Copy link
Member

@nwf nwf commented Nov 22, 2024

Pulling from #334 . This is much, much smaller than #320 and so hopefully that much easier to review. As usual, commit-by-commit is probably the right approach.

I am only so confident in the mscratchc changes, as they are not mechanically checked, though the version here does run the test suite on my machine (and several nearby versions, in some sense, do not). We might want to tear the bottom commits off this PR, as often happens.

sdk/core/switcher/entry.S Outdated Show resolved Hide resolved
@nwf nwf force-pushed the 202411-switcher-next branch 3 times, most recently from 4c1fb36 to c5356fc Compare November 26, 2024 16:01
* reference is not stored in memory (in the switcher, anyway), just mtdc.
* However, when this reference is extracted and sealed for the next
* context switch (in .Lexception_scheduler_call), the result will lack
* GL(obal), which will likely prove challenging for the scheduler.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which will likely prove challenging for the scheduler

I think this is understatement?! I'm not so familiar with the scheduler but presumably it keeps the sealed trusted stack pointers in global data structures. It sounds like this would only allow the scheduler to crash itself so not really an issue but I wonder if there are other ways a non-GL context pointer could make its way into the scheduler? switcher_interrupt_thread looks like it needs investigating.

@nwf nwf force-pushed the 202411-switcher-next branch 2 times, most recently from fc43793 to 29bed5e Compare November 26, 2024 19:09
@nwf nwf force-pushed the 202411-switcher-next branch 2 times, most recently from fc8ac57 to 27ddfd1 Compare November 29, 2024 21:13
@nwf nwf marked this pull request as ready for review November 29, 2024 21:25
@nwf nwf force-pushed the 202411-switcher-next branch 4 times, most recently from abaab69 to 1eddd0c Compare November 30, 2024 16:41
nwf added 11 commits December 9, 2024 21:15
Statically assert that the switcher's possibly imprecise test is precise

This changes no bytes in the generated code.
Add "trusted" to signal that these access the TrustedStack spill frame,
not the compartment_switcher_entry spill frame.
This lets us shave off an instruction.  Some additional creativity
inspired by @rmn30 lets us compress the update of csp and the three
spills other than the initial.
mtval is also exposed to the scheduler in .Lexception_scheduler_call
While we can't easily reuse the spill frame restore in
switcher_after_compartment_call, due to its interplay with the SHWM and
zeroing invariants, we can reuse .Lswitch_callee_dead_zeros.  This saves
a few bytes at the cost of a jump on an error path.
@nwf nwf force-pushed the 202411-switcher-next branch from 1eddd0c to bea6bec Compare December 9, 2024 21:50
@nwf nwf changed the title WIP: Next round of changes to the switcher Next round of changes to the switcher Dec 9, 2024
@nwf nwf merged commit e32da28 into CHERIoT-Platform:main Dec 10, 2024
6 checks passed
@nwf nwf deleted the 202411-switcher-next branch December 10, 2024 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants