Hi! On Mon, Aug 24, 2020 at 01:02:03PM -0500, Qing Zhao wrote: > > On Aug 24, 2020, at 12:49 PM, Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > On Wed, Aug 19, 2020 at 06:27:45PM -0500, Qing Zhao wrote: > >>> On Aug 19, 2020, at 5:57 PM, Segher Boessenkool > >>> <seg...@kernel.crashing.org> wrote: > >>> Numbers on how expensive this is (for what arch, in code size and in > >>> execution time) would be useful. If it is so expensive that no one will > >>> use it, it helps security at most none at all :-( > > > > Without numbers on this, no one can determine if it is a good tradeoff > > for them. And we (the GCC people) cannot know if it will be useful for > > enough users that it will be worth the effort for us. Which is why I > > keep hammering on this point. > I can collect some run-time overhead data on this, do you have a > recommendation on what test suite I can use > For this testing? (Is CPU2017 good enough)?
I would use something more real-life, not 12 small pieces of code. > > (The other side of the coin is how much this helps prevent exploitation; > > numbers on that would be good to see, too.) > > This can be well showed from the paper: > > "Clean the Scratch Registers: A Way to Mitigate Return-Oriented Programming > Attacks" > > https://ieeexplore.ieee.org/document/8445132 > <https://ieeexplore.ieee.org/document/8445132> > > Please take a look at this paper. As I told you before, that isn't open information, I cannot reply to any of that. Segher
