> On Sep 7, 2020, at 9:36 AM, Segher Boessenkool <seg...@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.
--- Begin Message ---> On Aug 25, 2020, at 9:05 AM, Qing Zhao via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > >> On Aug 25, 2020, at 1:41 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >> >>>> >>>>>> (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://urldefense.com/v3/__https://ieeexplore.ieee.org/document/8445132__;!!GqivPVa7Brio!JbdLvo54xB3ORTeZqpy_PwZsL9drNLaKjbg14bTKMOwxt8LWnjZ8gJWlqtlrFKPh$ >>>>> >>>>> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/8445132__;!!GqivPVa7Brio!JbdLvo54xB3ORTeZqpy_PwZsL9drNLaKjbg14bTKMOwxt8LWnjZ8gJWlqtlrFKPh$ >>>>> > >>>>> >>>>> Please take a look at this paper. >>>> >>>> As I told you before, that isn't open information, I cannot reply to >>>> any of that. >>> >>> A little confused here, what’s you mean by “open information”? Is the >>> information in a published paper not open information? >> >> No, because it is behind a paywall. > > Still don’t understand here: this paper has been published in the proceeding > of “ 2018 IEEE 29th International Conference on Application-specific Systems, > Architectures and Processors (ASAP)”. > If you want to read the complete version online, you need to pay for it. > > However, it’s still a published paper, and the information inside it should > be “open information”. > > So, what’s the definition of “open information” you have? > > I downloaded a PDF copy of this paper through my company’s paid account. But > I am not sure whether it’s legal for me to attach it to this mailing list? 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. There is some more information on this paper online though: https://urldefense.com/v3/__https://www.semanticscholar.org/paper/Clean-the-Scratch-Registers:-A-Way-to-Mitigate-Rong-Xie/6f2ce4fd31baa0f6c02f9eb5c57b90d39fe5fa13__;!!GqivPVa7Brio!I4MGz7_DH7Dtcfzmgz7MxfDNnuJO-CiNo1jUcp4OOQOiPi4uEEOfuoT7_1SSMt1D$ All the figures and tables in this paper are available in this link. In which, Figure 1 is an illustration of a typical ROP attack, please pay special attention on the “Gadgets”, which are carefully chosen machine instruction sequences that are already present in the machine's memory, Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code. Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine employing defenses that thwart simpler attacks. The paper identified the important features of ROP attack as following: "First, the destination of using gadget chains in usual is performing system call or system fucntion to perform malicious behaviour such as file access, network access and W ⊕ X disable. In most cases, the adversary would like to disable W ⊕ X. Because once W ⊕ X has been disabled, shellcode can be executed directly instead of rewritting shellcode to ROP chains which may cause some troubles for the adversary. Second, if the adversary performs ROP attacks using system call instruction, no matter on x86 or x64 architecture, the register would be used to pass parameter. Or if the adversary performs ROP attacks using system function such as “read” or “mprotect”, on x64 system, the register would still be used to pass parameters, as mentioned in subsection B and C.” As a result, the paper proposed the idea to zeroing scratch registers that pass parameters at the “return” insns to mitigate the ROP attack. 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. Table VI is the performance overhead of their implementation, it looks like very high, average 16.2X runtime overhead. However, this implementation is not use compiler to statically generate zeroing sequence, instead, it used "dynamic binary instrumentation at runtime “ to check every instruction to 1. Set/unset flags to check which scratch registers are used in the routine; 2. Whether the instruction is return instruction or not, if it’s is return, insert the zeroing used scratch register sequence before the “return” insn. Due to the above run-time dynamic instrumentation method, the high runtime overhead is expecting, I think. If we use GCC to statically check the “used” information and add zeroing sequence before return insn, the run-time overhead will be much smaller. I will provide run-time overhead information with the 2nd version of the patch by using CPU2017 applications. thanks. Qing > Qing > > >> >> Uros.
--- End Message ---
>> >> 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
