> On Aug 5, 2020, at 9:45 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Wed, Aug 5, 2020 at 5:34 AM H.J. Lu <hjl.to...@gmail.com
> <mailto:hjl.to...@gmail.com>> wrote:
>>
>> On Wed, Aug 5, 2020 at 5:31 AM Richard Biener <rguent...@suse.de> wrote:
>>>
>>>>>>>>>>>
>>>>>>>>>>> [PATCH] Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]
>>>>>>>>>>> command-line option and
>>>>>>>>>>> zero_call_used_regs("skip|used-gpr|all-gpr||used|all") function
>>>>>>>>>>> attribue:
>>>>>>>>>>>
>>>>>>>>>>> 1. -fzero-call-used-regs=skip and zero_call_used_regs("skip")
>>>>>>>>>>>
>>>>>>>>>>> Don't zero call-used registers upon function return.
>>>>>>>
>>>>>>> Does a return via EH unwinding also constitute a function return? I
>>>>>>> think you may want to have a finally handler or support in the unwinder
>>>>>>> for this? Then there's abnormal return via longjmp & friends, I guess
>>>>>>> there's nothing that can be done there besides patching glibc?
>>>>>>
>>>>>> Abnormal returns, like EH unwinding and longjmp, aren't covered by this
>>>>>> patch. Only normal returns are covered.
>>>>>
>>>>> What's the point then? Also specifically thinking about spill slots.
>>>>>
>>>>
>>>> The goal of this patch is to zero caller-saved registers upon normal
>>>> function return. Abnormal returns and spill slots are outside of the
>>>> scope of this patch.
>>>
>>> Sure, I can write a patch that spills some regs, writes zeros to them
>>> and then restores them. And the patch will fulfil what it was designed
>>> to do.
>>>
>>> Still I need to come up with a reason that this is a useful feature
>>> by its own for it to be accepted.
>>>
>>> I am asking for that reason. What's the reason for the "goal of this
>>> patch"? Why's that a useful goal on its own?
>>>
>>
>> Hi Victor,
>>
>> Can you provide some background information about how/why this feature
>> is used?
>>
>
> From The SECURE project and GCC in GCC Cauldron 2018:
>
> Speaker: Graham Markall
>
> The SECURE project is a 15 month program funded by Innovate UK, to
> take well known security techniques from academia and make them
> generally available in standard compilers, specfically GCC and LLVM.
> An explicit objective is for those techniques to be incorporated in
> the upstream versions of compilers. The Cauldron takes place in the
> final month of the project and this talk will present the technical
> details of some of the techniques implemented, and review those that
> are yet to be implemented. A particular focus of this talk will be on
> verifying that the implemetnation is correct, which can be a bigger
> challenge than the implementation.
>
> Techniques to be covered in the project include the following:
>
> Stack and register erasure. Ensuring that on return from a function,
> no data is left lying on the stack or in registers. Particular
> challenges are in dealing with inlining, shrink wrapping and caching.
>
> This patch implemens register erasure.
In addition to the above, Victor mentioned a paper that can provide good
background information
For this patch:
"Clean the Scratch Registers: A Way to Mitigate Return-Oriented Programming
Attacks"
https://ieeexplore.ieee.org/document/8445132
<https://ieeexplore.ieee.org/document/8445132>
The abstract of this paper is:
"With the implementation of W ⊕ X security model on computer system,
Return-Oriented Programming(ROP) has become the primary exploitation
technique for adversaries. Although many solutions that defend against ROP
exploits have been proposed, they still suffer from various shortcomings.
In this paper, we propose a new way to mitigate ROP attacks that are based
on return instructions. We clean the scratch registers which are also the
parameter registers based on the features of ROP malicious code and calling
convention. A prototype is implemented on x64-based Linux platform based on Pin.
Preliminary experimental results show that our method can efficiently mitigate
conventional ROP attacks."
Qing
>
>
> --
> H.J.
