PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Qing Zhao QING.ZHAO@ORACLE.COM
Tue Sep 8 14:55:19 GMT 2020



> On Sep 7, 2020, at 9:36 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> On Fri, Sep 04, 2020 at 02:00:41PM -0500, Qing Zhao wrote:
>>>> However, if we only clear USED registers, the worst case is 1.72% on average.  This overhead is very reasonable. 
>>> 
>>> No, that is the number I meant.  2% overhead is extremely much, unless
>>> this is magically super effective, and actually protects many things
>>> from exploitation (that aren't already protected some other way, SSP for
>>> example).
>> 
>> Then how about the 0.81% overhead on average for -fzero-call-used-regs=used_gpr_arg? 
> 
> That is still quite a lot.
> 
>> This option can be used to effectively mitigate ROP attack. 
> 
> Nice assertion.  Show it!

As I mentioned multiple times,  one important background of this patch is this  paper which was published at 2018 IEEE 29th International Conference on Application-specific Systems, Architectures and Processors (ASAP):

"Clean the Scratch Registers: A Way to Mitigate Return-Oriented Programming Attacks”

https://ieeexplore.ieee.org/document/8445132

Downloading this paper form IEEE needs a fee. I have downloaded it from my company’s account, however, After consulting, it turned out that I was not allowed to further forward the copy I downloaded through my company’s account to this alias. 

However, There is some more information on this paper online though:

https://www.semanticscholar.org/paper/Clean-the-Scratch-Registers:-A-Way-to-Mitigate-Rong-Xie/6f2ce4fd31baa0f6c02f9eb5c57b90d39fe5fa13

All the figures and tables in this paper are available in this link. 

In which, Table III, Table IV and Table V are the results of “zeroing scratch register mitigate ROP attack”. From the tables, zeroing scratch registers can successfully mitigate the ROP on all those benchmarks. 

What other information you need to show the effective of mitigation ROP attack?

> 
>>> Yes.  Which is why I asked for numbers of both sides of the equation:
>>> how much it costs, vs. how much value it brings.
-------------- next part --------------
An embedded message was scrubbed...
From: Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]
Date: Tue, 25 Aug 2020 17:31:53 -0500
Size: 14736
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200908/31f16909/attachment.eml>
-------------- next part --------------
>> 
>> Reasonable. 
> 
> I'm glad you agree :-)
> 
>>>> For compiler, we should provide such option to the users to satisfy their security need even though the runtime overhead.  Of course, during compiler implementation, we will do our best to minimize the runtime overhead.
>>> 
>>> There also is a real cost to the compiler *developers*.  Which is my
>>> prime worry here.  If this gives users at most marginal value, then it
>>> is real cost to us, but nothing to hold up to that.
>> 
>> Here, you mean the future maintenance  cost  for this part of the code?
> 
> Not just that.  *All* support costs, and consider all other
> optimisations it will interfere with, etc.

Many new features need these kinds of cost, as long as the new feature is necessary to provide important feature to the users.

From my understanding, this is a feature asked by kernel security people to improve kernel's security. And this feature has been in CLEAR LINUX since 2018 to improve kernel security on x86. 

thanks.

Qing
> 
> 
> Segher



More information about the Gcc-patches mailing list