Skip to content

[Reflection] Sanity-check metadata sizes in MetadataReader before reading. #37863

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 1 commit into from
Jun 14, 2021

Conversation

mikeash
Copy link
Contributor

@mikeash mikeash commented Jun 10, 2021

MetadataReader can be given corrupt or garbage data and we need to be able to handle it gracefully. When reading metadata, the full size to read is calculated from partial data. When we're given bad data, these calculated sizes can be enormous, up to 4GB. Trying to read that much data can cause address space exhaustion which leads to unpleasantness.

To avoid this, fix a limit of 1MB on metadata sizes, and fail early if the size is larger. No real-world metadata should ever be that large.

We also switch these potentially large calls to use the readBytes variant that returns a unique_ptr, rather than allocating a buffer and reading into it. Our clients typically implement that as the primitive, so this avoids an unnecessary extra data copy and extra address space usage for them. Clients that implement reading into a provided buffer as the primitive should see the same performance as before.

rdar://78621784

@mikeash mikeash requested review from jckarter, al45tair and tbkka June 10, 2021 18:04
@mikeash
Copy link
Contributor Author

mikeash commented Jun 10, 2021

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - d2a52ab39c8647c7f0094834f06dcee61fac91fb

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - d2a52ab39c8647c7f0094834f06dcee61fac91fb

@mikeash
Copy link
Contributor Author

mikeash commented Jun 10, 2021

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - d2a52ab39c8647c7f0094834f06dcee61fac91fb

…ding.

MetadataReader can be given corrupt or garbage data and we need to be able to handle it gracefully. When reading metadata, the full size to read is calculated from partial data. When we're given bad data, these calculated sizes can be enormous, up to 4GB. Trying to read that much data can cause address space exhaustion which leads to unpleasantness.

To avoid this, fix a limit of 1MB on metadata sizes, and fail early if the size is larger. No real-world metadata should ever be that large.

We also switch these potentially large calls to use the readBytes variant that returns a unique_ptr, rather than allocating a buffer and reading into it. Our clients typically implement that as the primitive, so this avoids an unnecessary extra data copy and extra address space usage for them. Clients that implement reading into a provided buffer as the primitive should see the same performance as before.

rdar://78621784
@mikeash mikeash force-pushed the metadata-reader-sane-sizes branch from d2a52ab to ebd9c21 Compare June 11, 2021 17:20
@mikeash
Copy link
Contributor Author

mikeash commented Jun 11, 2021

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - ebd9c21

@mikeash
Copy link
Contributor Author

mikeash commented Jun 11, 2021

@swift-ci please test macos platform

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - ebd9c21

@mikeash
Copy link
Contributor Author

mikeash commented Jun 14, 2021

@swift-ci please smoke test macos platform

1 similar comment
@mikeash
Copy link
Contributor Author

mikeash commented Jun 14, 2021

@swift-ci please smoke test macos platform

@mikeash mikeash merged commit d435af4 into swiftlang:main Jun 14, 2021
Copy link
Contributor

@al45tair al45tair left a comment

Choose a reason for hiding this comment

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

Looks good to me.

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

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

Looks good, thanks!

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.

4 participants