> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2025-04-09 08:30, Qing Zhao wrote: >> After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument. >> And all the size expression before the call to .ACCESS_WITH_SIZE might be >> dead >> code eliminated later in the RTL phases. >> So, I don’t think there will be run-time overhead concern. >> However, the IR size increase in the TREE optimization phase might impact the >> Optimization heuristics that base on IR size, for example, inlining >> decision, etc. >> That’s the major concern for me. > > I mean that the IR size estimation should also account for the fact that the > runtime overhead of .ACCESS_WITH_SIZE is zero.
Yes, theoretically, we could adjust all the impacted heuristics in GCC to ignore IR size increase due to the call to .ACCESS_WITH_SIZE and the size computations before it. That’s doable. -:) > >>> A good measure of this could be to get a sense of additional coverage one >>> could get for __bdos with this change vs without it for, e.g. the kernel. >>> You could maybe use fortify-metrics[1] to find that. >> Why there will be additional coverage with this change? (This change means to >> replace pointer reference with structure type with FAM by a call to >> .ACCESS_WITH_SIZE >> in C FE) >> Based on my current patch (expand the counted_by refs to size expressions by >> demand for __bdos), >> All the __bdos should be covered, right? > > Yes, I mean if you're concerned that there's a performance tradeoff due to > this change, you could quantify the coverage improvement to make the case > that there's a measurable improvement in security in the generated code, > which justifies the performance overhead. > > Something like: "The total coverage for __bdos improved by X% for the kernel > build, which justifies the additional overhead of up to N instructions for > the size expression caused by this patch". If the performance impact cannot be avoided, yes, we can justify like this. However, we can avoid this potential performance impact by not generating the call to .ACCESS_WITH_SIZE in C FE. Anyway, I agree that replacing every variable with a pointer type to a structure with FAM and counted_by attribute by size computations and a call to .ACCESS_WITH_SIZE in C FE might be a cleaner implementation. Need some study in C FE on how to implement this. Thanks. Qing > > Thanks, > Sid
