AaronBallman wrote: > Thanks! We essentially want a frontend mechanism to control the backend > subtarget features for the LFI subarchitecture. At the moment the only > subtarget features are `+no-lfi-stores` and `+no-lfi-loads`, but thinking > long-term there could more, such as a subtarget feature for sandbox size (4G > vs. configurable), or segmentation-based masking specifically for the > `x86_64_lfi` subarchitecture. > > It looks like other subarchitectures like `arm64ec` don't have configurations > knobs similar to what we want, but there are some security options like > `mbranch-protection` and `mharden-sls` that are somewhat similar to the > proposed `mlfi` option. Definitely open to suggestions though -- there was > some small discussion in the original LFI > [RFC](https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380) > about Clang options, but discussion mostly focused on backend support.
If we don't get a strong signal from the options maintainers on this PR, I think maybe an RFC specific to how this is surfaced in Clang might be reasonable. I don't expect there to be "no, we don't want Clang to expose any way to do LFI" kind of pushback, it's more to ensure the design has enough eyeballs on it (once we release with a user-facing option, changing the design gets much harder because you still have to support the old approach long enough for people to transition to the new approach). That said, I don't personally see anything that makes me think this PR is going in the wrong direction. https://github.com/llvm/llvm-project/pull/204689 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
