[clang] [llvm] [Clang][LFI] Add mlfi Clang option to control LFI subtarget features (PR #204689)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Thu Jul 9 08:21:07 PDT 2026
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
More information about the cfe-commits
mailing list