-
-
Notifications
You must be signed in to change notification settings - Fork 468
Fix asan according to aarch64 48-bit VMA #3650
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
rmalmain
wants to merge
35
commits into
main
Choose a base branch
from
fix_asan
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 12 commits
Commits
Show all changes
35 commits
Select commit
Hold shift + click to select a range
e1b4d7f
fix asan according to aarch64 48-bit VMA
rmalmain b733546
oops
rmalmain ff95740
testing stuff
rmalmain e5fd6d9
verbose missing arch
rmalmain 45ff7d5
fix
rmalmain caf0799
fix
rmalmain 3ec3e2f
default layout
rmalmain fb09291
fix
rmalmain d0a95a4
more details
rmalmain bb15c7c
more details
rmalmain 26ac3da
more details
rmalmain fd08e30
fix
rmalmain 5de7868
default vma for aarch64
rmalmain 0dbc4f8
fmt
rmalmain 27e0b9b
fix
rmalmain 2ea50f6
use weak symbols to define shadow base in qemu-libafl-bridge
rmalmain f586856
Merge branch 'main' into fix_asan
rmalmain ade7380
use host arch for test
rmalmain 091106d
changed default layout to old one
rmalmain db186af
docs, fmt
rmalmain 0bd2c2a
nostd
rmalmain bf9064d
fmt
rmalmain 90f8343
update wrong qemu paths in github action files
rmalmain 5bc20bf
update libafl_qemu_asan_*
rmalmain 55f5737
remove mimalloc from qemu_launcher. it causes asan host issues due to…
rmalmain 356611f
fmt
rmalmain d70be3d
Merge branch 'main' into fix_asan
rmalmain b8ba558
clippy
rmalmain f1368e0
fix clippy
rmalmain 6640017
temporarily ignore qemu_coverage tests
rmalmain b8482cb
useless now
rmalmain b6dcd20
ignore qemu_tmin tests for now
rmalmain 38c4c4b
fmt, clippy
rmalmain 3663563
Merge branch 'main' into fix_asan
rmalmain e903aab
Merge branch 'main' into fix_asan
rmalmain File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There may be an easier way to detect the supported VA space. See "52-bit userspace VAs" at the bottom of this article. https://opensource.com/article/20/12/52-bit-arm64-kernel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i found the linux doc explaining the same things there: https://www.kernel.org/doc/html/latest/arch/arm64/memory.html
afaik this information is only accessible in kernel land, and not in userland.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the article is found said you can call mmap with a hint value to discover it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from what i understand it doesn't seem to be the exact purpose of calling mmap with
~0UL. it just hints to the kernel you are ready to receive addresses up to 52 bits, but it doesn't mean the kernel will even give you a 52bit address. also, it would not detect smaller vmas (39, 42, etc.), even if i guess this is not very common nowadays.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes. Good point. Might be worth scanning the current address map to see the highest address currently in use as a fallback? Or using the current address space to work out where to request new mappings when probing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i thought about that, but i think the problem is a bit more tricky.
according to the documentation, linux will give by default 48 bit addresses, and give 52bit addresses if the application supports it. so i guess you could have an address map that looks like it's 48bits until later on the app requests a (possibly) 52bit address with the
~0ULtrick. so i'm not sure it's easy to know in advance if the app will use 48bits or 52bits just by looking at the current address space.with
find_max_vaddr_bits, the idea is to know the 'real' max limit of the vma in the current environment, whatever the app does afterwards. we could end up using the 52-bits layout even though the app only gets 48-bits addresses, but i don't think that's a problem?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking if you know the current max va, then you know any requests to map higher addresses should only fail if the requested address is invalid rather than a collision? Maybe able to determine based on the value of errno too? Eexist vs einval?