On Thu, Sep 3, 2020 at 6:13 PM Kees Cook via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote: > > On average, all the options starting with “used_…” (i.e, only the > > registers that are used in the routine will be zeroed) have very low > > runtime overheads, at most 1.72% for integer benchmarks, and 1.17% for FP > > benchmarks. > > If all the registers will be zeroed, the runtime overhead is bigger, > > all_arg is 5.7%, all_gpr is 3.5%, and all is 17.56% for integer benchmarks > > on average. > > Looks like the overhead of zeroing vector registers is much bigger. > > > > For ROP mitigation, -fzero-call-used-regs=used-gpr-arg should be enough, > > the runtime overhead with this is very small. > > That looks great; thanks for doing those tests! > > (And it seems like these benchmarks are kind of a "worst case" scenario > with regard to performance, yes? As in it's mostly tight call loops?)
That's true of some of them but definitely not all - the GCC benchmark springs to mind in SPEC as having quite a flat profile, so I'd take a look there and probe a bit more in that one to see what happens. Don't ask me what else , that's all I have in my cache this evening :) I'd also query the "average" slowdown metric in those numbers as something that's being measured in a different way here. IIRC the SPEC scores for int and FP are computed with a geometric mean of the individual ratios of each of the benchmark. Thus I don't think the average of the slowdowns is enough to talk about slowdowns for the benchmark suite. A quick calculation of the arithmetic mean of column B in my head suggests that it's the arithmetic mean of all the slowdowns ? i.e. Slowdown (Geometric Mean (x, y, z, ....)) != Arithmetic mean ( Slowdown (x), Slowdown (y) .....) So another metric to look at would be to look at the Slowdown of your estimated (probably non-reportable) SPEC scores as well to get a more "spec like" metric. regards Ramana > > -- > Kees Cook
