phyBrackets wrote: My main concern is still the SROA interaction, when SROA splits a struct that contains for eg. `char[32]` into separate allocas, metadata on the original alloca gets silently dropped, unless SROA explicitly knows to propagate it, and nobody gets a compile error or test failure when that happens. With the Intrinsic, SROA is forced to deal with it because it's a use of the alloca, if it doesn't handle it, the alloca can't be deleted, and someone notices immediately. That said @nikic suggestion of negative metadata does address the security side of my concern, if the metadata gets dropped, the default becomes over protection, a perf cost, rather than silent loss of the canary, which is a security regression, and I think that's an acceptable failure mode. What it doesn't full address though is the layout quality, the `IsLarge` classification determines whether a buffer lands in the "large" or "small" bucket relative to the canary, and if that hint is lost through a transformation, the stack layout becomes suboptimal even though protection is technically still present. So whatever encoding we settle on, `IsLarge` bit is important, I think we need an explicit SROA test case where a struct containing a protectable array gets split, to make sure the classification actually survives end to end.
https://github.com/llvm/llvm-project/pull/183623 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
