> 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://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, 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.
