Skip to content

Add more assertions #5245

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

Merged
merged 7 commits into from
Jul 15, 2025
Merged

Add more assertions #5245

merged 7 commits into from
Jul 15, 2025

Conversation

ShadowCurse
Copy link
Contributor

@ShadowCurse ShadowCurse commented Jun 3, 2025

Changes

Add asserts in places where we have strong assumptions about inner workings of the code.

Reason

Adding asserts improves security posture and allows assumptions to be stated more verbosely.
These asserts are only related to the parts of the code which do not depend on the user input.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkstyle to verify that the PR passes the
    automated style checks.
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md.
  • If a specific issue led to this PR, this PR closes the issue.
  • When making API changes, I have followed the
    Runbook for Firecracker API changes.
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests.
  • I have linked an issue to every new TODO.

  • This functionality cannot be added in rust-vmm.

Copy link

codecov bot commented Jun 3, 2025

Codecov Report

Attention: Patch coverage is 94.11765% with 2 lines in your changes missing coverage. Please review.

Project coverage is 82.97%. Comparing base (68c2b59) to head (d62cd90).
Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
src/vmm/src/persist.rs 33.33% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5245      +/-   ##
==========================================
+ Coverage   82.93%   82.97%   +0.04%     
==========================================
  Files         250      250              
  Lines       26873    26844      -29     
==========================================
- Hits        22286    22274      -12     
+ Misses       4587     4570      -17     
Flag Coverage Δ
5.10-c5n.metal 83.41% <100.00%> (-0.02%) ⬇️
5.10-m5n.metal 83.41% <100.00%> (-0.01%) ⬇️
5.10-m6a.metal 82.62% <100.00%> (-0.02%) ⬇️
5.10-m6g.metal 79.23% <94.11%> (-0.02%) ⬇️
5.10-m6i.metal 83.40% <100.00%> (-0.02%) ⬇️
5.10-m7a.metal-48xl 82.61% <100.00%> (?)
5.10-m7g.metal 79.23% <94.11%> (-0.02%) ⬇️
5.10-m7i.metal-24xl 83.37% <100.00%> (?)
5.10-m7i.metal-48xl 83.37% <100.00%> (?)
5.10-m8g.metal-24xl 79.23% <94.11%> (?)
5.10-m8g.metal-48xl 79.23% <94.11%> (?)
6.1-c5n.metal 83.46% <100.00%> (-0.02%) ⬇️
6.1-m5n.metal 83.46% <100.00%> (-0.01%) ⬇️
6.1-m6a.metal 82.68% <100.00%> (-0.01%) ⬇️
6.1-m6g.metal 79.23% <94.11%> (-0.02%) ⬇️
6.1-m6i.metal 83.44% <100.00%> (-0.02%) ⬇️
6.1-m7a.metal-48xl 82.66% <100.00%> (?)
6.1-m7g.metal 79.23% <94.11%> (-0.02%) ⬇️
6.1-m7i.metal-24xl 83.47% <100.00%> (?)
6.1-m7i.metal-48xl 83.47% <100.00%> (?)
6.1-m8g.metal-24xl 79.23% <94.11%> (?)
6.1-m8g.metal-48xl 79.23% <94.11%> (?)

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.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 20 times, most recently from 70239eb to ed878a1 Compare June 11, 2025 10:32
@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 4 times, most recently from 169752b to b7d4bb8 Compare June 25, 2025 11:08
@ShadowCurse ShadowCurse changed the title Misc fixes Add more assertions Jun 25, 2025
@ShadowCurse ShadowCurse marked this pull request as ready for review June 25, 2025 11:26
@ShadowCurse ShadowCurse self-assigned this Jun 25, 2025
@ShadowCurse ShadowCurse added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Jun 25, 2025
@roypat roypat enabled auto-merge (rebase) June 26, 2025 10:02
@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 5 times, most recently from b32041a to 477677b Compare July 3, 2025 15:38
roypat
roypat previously approved these changes Jul 3, 2025
@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 3 times, most recently from c7a8490 to 1c1daa9 Compare July 10, 2025 10:36
Copy link
Contributor

@Manciukic Manciukic left a comment

Choose a reason for hiding this comment

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

I'm still struggling to understand the value added by this PR, but I don't have strong opinions against it. Could you expand the reasons a bit more in the PR description?

@ShadowCurse
Copy link
Contributor Author

@Manciukic added reasons to the PR description.

@roypat roypat requested a review from Manciukic July 15, 2025 10:06
It is reasonable to assume that we will not have more than u32::MAX
memory slots since kernel only returns i32 from a query syscall.
Enforce this with `.expect` calls and change the type of `max_memslots`
to u32.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Replaces never used error result type wit optional.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Vcpu TLS must only be initialized once.
Enforce this with an assertion.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Move setting of signal handler into vcpu init to
prevent race condition between setting TLS and signal handler
using TLS.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
- The reset must be called only once on vcpu drop, so move it
directly into the Drop impl.
- Replace errors with asserts since there is an assumption that TLS
will always hold correct vcpu pointer for a given thread (except in
tests).

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Merge run_on_thread_local into signal handler since it is
only used there.
The error returned from run_on_thread_local was ignored, so
instead replace it with logic to only use vcpu ptr if
TLS is initialized, without returning any errors.
The reason for not asserting on TLS being initialized here
is that during Firecracker shutdown, vcpus will be destroyed
and TLS will be reset. If signal will be send to Firecracker
during that time, the TLS accessed from a signal handler will
be empty. But this is expected, so no assertions/panics are needed.

Because Rust is a good language, it does not allow to reference
TLS_VCPU_PTR definded inside impl block inside the signal_handler
function. So move the TLS_VCPU_PTR definition outside the Vcpu impl
block.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Instead of storing the pointer to the Vcpu in the TLS,
store the mmapped `kvm_run` struct instead. This way the Drop
implementation for Vcpu is no longer required, since the
mmapped `kvm_run` will remain valid until TLS is destroyed by
the thread Drop impl.
This also removes `unsafe` code from the implementation.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
@roypat roypat merged commit 4d11998 into firecracker-microvm:main Jul 15, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting review Indicates that a pull request is ready to be reviewed Type: Enhancement Indicates new feature requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants