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

LLVM fork issues #386

Open
fw-immunant opened this issue Aug 1, 2024 · 1 comment
Open

LLVM fork issues #386

fw-immunant opened this issue Aug 1, 2024 · 1 comment
Assignees
Labels
ARM ARM related work

Comments

@fw-immunant
Copy link
Contributor

Attempting to enable MTE led me to realize that when IA2 is compiled in non-release mode we were not inserting our pointer tagging at all in at least some functions (such as the ia2_compartment_destructor_N functions). This does make sense as our logic lives inside an optimization pass (AArch64DeadRegisterDefinitions) that may not always be applied.

When passing -O2 or -O3, however, we run into a bunch of problems, starting with unhandled instructions. I've been trying to add support for more instructions, but I think we may need to step back a bit and reconsider how our changes fit into Clang's compilation pipeline.

Our changes assume each AArch64 MachineInstruction that counts as a load or store accepts its address in a particular register operand, but this does not seem to be true. For example, STRQui accepts its address in operand 1, but this operand is sometimes a register and sometimes an immediate such as %stack.0.shared_sections:

STRQui killed %9:fpr128, %stack.0.shared_sections, 0

I'm not sure whether this is referring to the result of an alloca (which, if we're tagging stack references, we'll need to tag) or something else. At the very least, we can't simply assume that the address operand is in a register.

It also appears that after optimizations some of the instructions are working with 32-bit quantities that we'll need to treat differently than inserting references to (64-bit) x18.

I wonder if it makes sense to revisit inserting our tagging logic at a different point in the compilation pipeline, or if we can make the necessary changes in a robust way where they are.

At the very least, we should avoid silently failing to insert tagging when compiling sans optimizations.

@fw-immunant fw-immunant added the ARM ARM related work label Aug 1, 2024
@fw-immunant fw-immunant self-assigned this Sep 3, 2024
@fw-immunant
Copy link
Contributor Author

This is solved in the second version of our Clang patches: immunant/llvm-project#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARM ARM related work
Projects
None yet
Development

No branches or pull requests

1 participant