Re: Back porting to GCC11/GCC12: Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

2022-05-24 Thread Qing Zhao via Gcc-patches
Pushed to both gcc11 and gcc12.

thanks.

Qing

> On May 24, 2022, at 1:19 AM, Richard Biener  wrote:
> 
> On Mon, 23 May 2022, Qing Zhao wrote:
> 
>> Hi,
>> 
>> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped 
>> and regress tested on both x86 and aarch64, no any issues.
>> 
>> Can I committed them to both GCC11 and GCC12 branches?
> 
> Yes.
> 
> Thanks,
> Richard.
> 
>> Thanks.
>> 
>> 
>> 
>> 
>>> On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches 
>>>  wrote:
>>> 
>>> 
>>> 
 On May 10, 2022, at 1:12 AM, Richard Biener  wrote:
 
 On Mon, 9 May 2022, Uros Bizjak wrote:
 
> On Mon, May 9, 2022 at 5:44 PM Qing Zhao  wrote:
>> 
>> Another question:
>> 
>> I think that this patch might need to be back ported to Gcc12 and GCC11.
>> 
>> What?s your opinion on this?
> 
> It is not a regression, so following general rules, the patch should
> not be backported. OTOH, the patch creates functionally equivalent
> code, better in some security aspects. The functionality is also
> hidden behind some non-default flag, so I think if release managers
> (CC'd) are OK with the backport, I'd give it a technical approval.
> 
>> If so, when can I backport it?
> 
> Let's keep it in the mainline for a week or two, before backporting it
> to non-EoL branches.
 
 OK from my POV after a week or two on trunk.
>>> 
>>> Sure, I will do the back porting after two weeks.
>>> 
>>> thanks.
>>> 
>>> Qing
 
 Richard.
 
> Uros.
> 
>> 
>> thanks.
>> 
>> Qing
>> 
>>> On May 7, 2022, at 4:06 AM, Uros Bizjak  wrote:
>>> 
>>> On Fri, May 6, 2022 at 6:42 PM Qing Zhao  wrote:
 
 
 
> On May 6, 2022, at 10:58 AM, Uros Bizjak  wrote:
> 
> On Fri, May 6, 2022 at 4:29 PM Qing Zhao  wrote:
>> 
>> Hi,
>> 
>> As Kee?s requested in this PR: 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
>> 
>> =
>> 
>> Currently -fzero-call-used-regs will use a pattern of:
>> 
>> XOR regA,regA
>> MOV regA,regB
>> MOV regA,regC
>> ...
>> RET
>> 
>> However, this introduces both a register ordering dependency (e.g. 
>> the CPU cannot clear regB without clearing regA first), and while 
>> greatly reduces available ROP gadgets, it does technically leave a 
>> set of "MOV" ROP gadgets at the end of functions (e.g. "MOV 
>> regA,regC; RET").
>> 
>> Please switch to always using XOR:
>> 
>> XOR regA,regA
>> XOR regB,regB
>> XOR regC,regC
>> ...
>> RET
>> 
>> ===
>> 
>> This patch switch all MOV to XOR on i386.
>> 
>> Bootstrapped and regresstion tested on x86_64-linux-gnu.
>> 
>> Okay for gcc13?
>> 
>> Thanks.
>> 
>> Qing
>> 
>> ==
> 
>> gcc/ChangeLog:
>> 
>> * config/i386/i386.cc (zero_all_mm_registers): Use SET to zero 
>> instead
>> of MOV for zeroing scratch registers.
>> (ix86_zero_call_used_regs): Likewise.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
>> -fno-PIC.
>> * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
>> * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
>> -fno-PIC.
>> * gcc.target/i386/zero-scratch-regs-16.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-17.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
>> -fno-PIC, adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
>> -fno-PIC.
>> * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
>> * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
>> -fno-PIC, Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-23.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-26.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-27.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-28.c: Likewise.
>> * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
>> * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
>> * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
>> 

Re: Back porting to GCC11/GCC12: Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

2022-05-24 Thread Richard Biener via Gcc-patches
On Mon, 23 May 2022, Qing Zhao wrote:

> Hi,
> 
> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped 
> and regress tested on both x86 and aarch64, no any issues.
> 
> Can I committed them to both GCC11 and GCC12 branches?

Yes.

Thanks,
Richard.

> Thanks.
> 
> 
> 
> 
> > On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches 
> >  wrote:
> >
> >
> >
> >> On May 10, 2022, at 1:12 AM, Richard Biener  wrote:
> >>
> >> On Mon, 9 May 2022, Uros Bizjak wrote:
> >>
> >>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao  wrote:
> 
>  Another question:
> 
>  I think that this patch might need to be back ported to Gcc12 and GCC11.
> 
>  What?s your opinion on this?
> >>>
> >>> It is not a regression, so following general rules, the patch should
> >>> not be backported. OTOH, the patch creates functionally equivalent
> >>> code, better in some security aspects. The functionality is also
> >>> hidden behind some non-default flag, so I think if release managers
> >>> (CC'd) are OK with the backport, I'd give it a technical approval.
> >>>
>  If so, when can I backport it?
> >>>
> >>> Let's keep it in the mainline for a week or two, before backporting it
> >>> to non-EoL branches.
> >>
> >> OK from my POV after a week or two on trunk.
> >
> > Sure, I will do the back porting after two weeks.
> >
> > thanks.
> >
> > Qing
> >>
> >> Richard.
> >>
> >>> Uros.
> >>>
> 
>  thanks.
> 
>  Qing
> 
> > On May 7, 2022, at 4:06 AM, Uros Bizjak  wrote:
> >
> > On Fri, May 6, 2022 at 6:42 PM Qing Zhao  wrote:
> >>
> >>
> >>
> >>> On May 6, 2022, at 10:58 AM, Uros Bizjak  wrote:
> >>>
> >>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao  wrote:
> 
>  Hi,
> 
>  As Kee?s requested in this PR: 
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
> 
>  =
> 
>  Currently -fzero-call-used-regs will use a pattern of:
> 
>  XOR regA,regA
>  MOV regA,regB
>  MOV regA,regC
>  ...
>  RET
> 
>  However, this introduces both a register ordering dependency (e.g. 
>  the CPU cannot clear regB without clearing regA first), and while 
>  greatly reduces available ROP gadgets, it does technically leave a 
>  set of "MOV" ROP gadgets at the end of functions (e.g. "MOV 
>  regA,regC; RET").
> 
>  Please switch to always using XOR:
> 
>  XOR regA,regA
>  XOR regB,regB
>  XOR regC,regC
>  ...
>  RET
> 
>  ===
> 
>  This patch switch all MOV to XOR on i386.
> 
>  Bootstrapped and regresstion tested on x86_64-linux-gnu.
> 
>  Okay for gcc13?
> 
>  Thanks.
> 
>  Qing
> 
>  ==
> >>>
>  gcc/ChangeLog:
> 
>  * config/i386/i386.cc (zero_all_mm_registers): Use SET to zero 
>  instead
>  of MOV for zeroing scratch registers.
>  (ix86_zero_call_used_regs): Likewise.
> 
>  gcc/testsuite/ChangeLog:
> 
>  * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
>  -fno-PIC.
>  * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
>  * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
>  -fno-PIC.
>  * gcc.target/i386/zero-scratch-regs-16.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-17.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
>  -fno-PIC, adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
>  -fno-PIC.
>  * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
>  * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
>  -fno-PIC, Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-23.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-26.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-27.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-28.c: Likewise.
>  * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
>  * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
>  -fno-PIC.
>  * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor.
>  * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector.
>  * 

Back porting to GCC11/GCC12: Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

2022-05-23 Thread Qing Zhao via Gcc-patches
Hi,

I have added the patch to GCC11 and GCC12 in my local area and bootstrapped and 
regress tested on both x86 and aarch64, no any issues.

Can I committed them to both GCC11 and GCC12 branches?

Thanks.




> On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches 
>  wrote:
>
>
>
>> On May 10, 2022, at 1:12 AM, Richard Biener  wrote:
>>
>> On Mon, 9 May 2022, Uros Bizjak wrote:
>>
>>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao  wrote:

 Another question:

 I think that this patch might need to be back ported to Gcc12 and GCC11.

 What?s your opinion on this?
>>>
>>> It is not a regression, so following general rules, the patch should
>>> not be backported. OTOH, the patch creates functionally equivalent
>>> code, better in some security aspects. The functionality is also
>>> hidden behind some non-default flag, so I think if release managers
>>> (CC'd) are OK with the backport, I'd give it a technical approval.
>>>
 If so, when can I backport it?
>>>
>>> Let's keep it in the mainline for a week or two, before backporting it
>>> to non-EoL branches.
>>
>> OK from my POV after a week or two on trunk.
>
> Sure, I will do the back porting after two weeks.
>
> thanks.
>
> Qing
>>
>> Richard.
>>
>>> Uros.
>>>

 thanks.

 Qing

> On May 7, 2022, at 4:06 AM, Uros Bizjak  wrote:
>
> On Fri, May 6, 2022 at 6:42 PM Qing Zhao  wrote:
>>
>>
>>
>>> On May 6, 2022, at 10:58 AM, Uros Bizjak  wrote:
>>>
>>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao  wrote:

 Hi,

 As Kee?s requested in this PR: 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891

 =

 Currently -fzero-call-used-regs will use a pattern of:

 XOR regA,regA
 MOV regA,regB
 MOV regA,regC
 ...
 RET

 However, this introduces both a register ordering dependency (e.g. the 
 CPU cannot clear regB without clearing regA first), and while greatly 
 reduces available ROP gadgets, it does technically leave a set of 
 "MOV" ROP gadgets at the end of functions (e.g. "MOV regA,regC; RET").

 Please switch to always using XOR:

 XOR regA,regA
 XOR regB,regB
 XOR regC,regC
 ...
 RET

 ===

 This patch switch all MOV to XOR on i386.

 Bootstrapped and regresstion tested on x86_64-linux-gnu.

 Okay for gcc13?

 Thanks.

 Qing

 ==
>>>
 gcc/ChangeLog:

 * config/i386/i386.cc (zero_all_mm_registers): Use SET to zero instead
 of MOV for zeroing scratch registers.
 (ix86_zero_call_used_regs): Likewise.

 gcc/testsuite/ChangeLog:

 * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
 -fno-PIC.
 * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
 * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
 -fno-PIC.
 * gcc.target/i386/zero-scratch-regs-16.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-17.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
 -fno-PIC, adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
 -fno-PIC.
 * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
 * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
 -fno-PIC, Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-23.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-26.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-27.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-28.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
 * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
 -fno-PIC.
 * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector.
 * gcc.target/i386/zero-scratch-regs-7.c: Likewise.
 * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor.
 * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector.
>>>
>>> Please use something like the attached (functionally equivalent) patch
>>> for the last hunk of your patch.
>>
>> Sure, I will update the code.
>>>
>>>