Skip to content

[PM-18100] Add mlock and memfd_secret implementations #125

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

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

dani-garcia
Copy link
Member

@dani-garcia dani-garcia commented Jan 20, 2025

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-18100

📔 Objective

Implement some new backends for the KeyStore that use the OS memory protections:

  • memfd_secret: On newer Linux only, but should protect any content in the store from being read from external programs, even if running as root. It also provides some minor protection against malicious kernel modules, but that can be bypassed.
  • mlock: Supported on Unix. Doesn't provide any real protection from reads, but ensures that the keys aren't swapped to disk. Note that Windows also supports a similar VirtualLock API, but I've had some trouble with the crates depending on an older windows crate, so it's not enabled for Windows yet.

Note that for this implementation to be useful, we need to revert the boxing of keys so they are stack allocated. This would mean either not exposing them publicly, or having a separate internal key type.

This requires a MSRV bump to 1.80 for the use of LazyLock, but #256 requires 1.82 anyway.

For this implementation we're using the hashbrown crate, which allows us to create a HashMap that uses a custom allocator. I've implemented a custom allocator for the two protections mentioned above.

To ensure that this works correctly, I've implemented a simple fuzzing test that executes thousands of random operations and compares the results and contents of these new backeds against the basic rust hashmap that we're using now.

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
    team

🦮 Reviewer guidelines

  • 👍 (:+1:) or similar for great changes
  • 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
  • ❓ (:question:) for questions
  • 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
    issue and could potentially benefit from discussion
  • 🎨 (:art:) for suggestions / improvements
  • ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
  • 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
  • ⛏ (:pick:) for minor or nitpick changes

Copy link
Contributor

github-actions bot commented Jan 20, 2025

Logo
Checkmarx One – Scan Summary & Details109c4e42-f59e-4f09-b1d8-44e6411fdba4

Great job, no security vulnerabilities found in this Pull Request

Copy link

codecov bot commented Jan 20, 2025

Codecov Report

Attention: Patch coverage is 84.21053% with 33 lines in your changes missing coverage. Please review.

Project coverage is 70.58%. Comparing base (0e948af) to head (a3dd159).

Files with missing lines Patch % Lines
...den-crypto/src/store/backend/implementation/mod.rs 85.41% 14 Missing ⚠️
.../implementation/custom_alloc/linux_memfd_secret.rs 78.00% 11 Missing ⚠️
...tore/backend/implementation/custom_alloc/malloc.rs 77.77% 8 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #125      +/-   ##
==========================================
+ Coverage   70.38%   70.58%   +0.19%     
==========================================
  Files         215      218       +3     
  Lines       17043    17250     +207     
==========================================
+ Hits        11996    12176     +180     
- Misses       5047     5074      +27     

☔ 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.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@dani-garcia dani-garcia force-pushed the ps/secure-crypto-service-backends branch from e4906dc to 0aa0b89 Compare January 21, 2025 18:27
Base automatically changed from ps/secure-crypto-service to main February 3, 2025 17:55
@dani-garcia dani-garcia force-pushed the ps/secure-crypto-service-backends branch from 0aa0b89 to c52afa4 Compare February 3, 2025 17:57
@dani-garcia dani-garcia changed the title Add mlock and memfd_secret implementations [PM-18100] Add mlock and memfd_secret implementations Feb 7, 2025

This comment was marked as resolved.

@dani-garcia dani-garcia marked this pull request as ready for review May 2, 2025 16:27
@dani-garcia dani-garcia requested a review from a team as a code owner May 2, 2025 16:27
@dani-garcia dani-garcia requested review from addisonbeck and Hinton May 2, 2025 16:27
@addisonbeck
Copy link
Contributor

This looks fine to me, but I am definitely not the perfect person for review. I'll let @Hinton take a look before approving. Maybe even @coroiu taking a look would be nice.

@addisonbeck addisonbeck requested a review from coroiu June 11, 2025 20:13
Copy link
Contributor

@coroiu coroiu left a comment

Choose a reason for hiding this comment

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

@dani-garcia In the description you say

Note that for this implementation to be useful, we need to revert the boxing of keys so they are stack allocated. This would mean either not exposing them publicly, or having a separate internal key type.

Does this mean that we need to start using the KeyRef traits? Why can't these be exposed publicly?

Comment on lines +17 to +23
// Check that the pointer is readable and writable
let result = unsafe {
let ptr = ptr.as_ptr() as *mut u8;
*ptr = 30;
*ptr += 107;
*ptr == 137
};
Copy link
Contributor

Choose a reason for hiding this comment

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

question: what happens if it isn't? What is returned as ptr if memfd_secret isn't supported? Trying to write to an invalid pointer/pointer to memory outside of the process should cause a segmentation fault, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

In theory it shouldn't happen, the memfd_secret_sized function should return None if it can't allocate or the feature is not supported, and if it returns Some, then the file descripto is valid and open for read/write according to the API: https://man7.org/linux/man-pages/man2/memfd_secret.2.html#DESCRIPTION.

This was added more as a sanity check during development, so it can probably be removed.

return Err(AllocError);
};

// Check that the pointer is aligned to the requested alignment.
Copy link
Contributor

Choose a reason for hiding this comment

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

question: is aligned or isn't aligned?

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried to mean validate that the pointer is aligned, return an error if not but I can see how that's a bit confusing.

So the case inside the if, we check if it's not aligned to return an error, and only continue after the if when the pointer is valid. I'll try to rewrite the comment to be more clear.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ohh yeah ok that makes sense, interesting how that can be interpreted differently :D Thanks!

@dani-garcia
Copy link
Member Author

@dani-garcia In the description you say

Note that for this implementation to be useful, we need to revert the boxing of keys so they are stack allocated. This would mean either not exposing them publicly, or having a separate internal key type.

Does this mean that we need to start using the KeyRef traits? Why can't these be exposed publicly?

So what these memory protection schemes do is protect a region of memory where we place the keys. In this case inside a hashmap. The reason why we apply the protection to the hashmap and not the individual keys is that some of these operations are slow, and others require page alignment, which would be wasteful if we did it per key.

The problem is that if the keys are not stack allocated, then the only thing we're protecting is the pointers to the keys, as the keys would be allocated somewhere else. If you check the definition of our keys, they are all boxed inside:

struct Aes256CbcKey {
     enc_key: Pin<Box<GenericArray<u8, U32>>>,
}

This was done initially to avoid the keys being stack allocated, which makes it easier to accidentally make multiple copies in memory when moving the keys around, but it also invalidates the use of combined memory protections like these. If we remove this boxing to make the memfd_secret implementation useful, then that means we go back to the danger of having to be careful with the keys.

This leaves us with a few options if we want these protections to be effective:

  • We remove any use of the keys outside the bitwarden-crypto, and then we can make them crate private, and just be careful with them in the few places that use them. The majority of the code would be dealing with KeyIds only. This is something we'd want to happen anyway, to avoid users having direct access to key material.
  • We split the keys into two: pub(crate) InternalAes256CbcKey(GenericArray<u8, U32>) and pub Aes256CbcKey(Pin<Box<InternalAes256CbcKey>>) KeyStore only stores the internal variant, and the public variant is just a boxed wrapper.
  • We just remove the boxing and keep the keys public, this would be easiest to implement, but it would mean backsliding a bit for the cases where we use the keys from non-crypto apis, which is still a few.

Copy link

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.

3 participants