You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
: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.
The text was updated successfully, but these errors were encountered: