Re: GCC 8.1 Release Candidate available from gcc.gnu.org
Jakub Jelinek on 2018/4/25 18:04 wrote: https://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425/ The first release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425 and shortly its mirrors. It has been generated from SVN revision 259636. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. Hi, Jakub, There are 5 nds32-specific patches in the mainline to fix incorrect assembly code output: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01201.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01202.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01203.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01204.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01205.html I would like to have them in the gcc-8-branch before GCC 8.1 is released. Are those patches OK to be backported from mainline? Best regards, jasonwucj
Re: Stack protector: leak of guard's address on stack
Hi there, Any objection to filing a CVE for that? Best regards, Thomas On 19 April 2018 at 18:17, Thomas Preudhomme wrote: > Hi, > > For stack protector to be robust, at no point in time the guard against > which the canari is compared must be spilled to the stack. This is achieved > by having dedicated insn pattern for setting the canari and comparing it > against the guard which doesn't reflect at RTL what is happening. However > computing the address of the guard is done using standard movsi pattern and > can thus be spilled (see PR85434). I'm reaching out to the community for > ideas on how to avoid this. > > Spilling is more likely in the context of PIC where the address is loaded > from the GOT and is thus not rematerialized. Likewise CSE make things worse > by reusing the address computed in the prologue to set the canari later in > the epilogue when performing the check, thereby being sensitive to peak > register pressure in the function. Aarch64 and I believe x86 backends don't > have the CSE issue for PIC because the GOT access is represented by an > outer UNSPEC whereas arm backend represent it by a MEM of an UNSPEC. I > think all targets are prone to issues in theory because the scheduler could > reorder the GOT access away from the guard/canari comparison which would > make a spill possible. > > So far my feeling is that we would need new patterns that also cover the > guard's address computation but that would make such a pattern quite > complex to cover all the possible address. > > Thoughts? > > Best regards, > > Thomas >
Re: Stack protector: leak of guard's address on stack
On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas Preudhomme wrote: > For stack protector to be robust, at no point in time the guard against > which the canari is compared must be spilled to the stack. This is achieved > by having dedicated insn pattern for setting the canari and comparing it > against the guard which doesn't reflect at RTL what is happening. However > computing the address of the guard is done using standard movsi pattern and > can thus be spilled (see PR85434). I'm reaching out to the community for > ideas on how to avoid this. Usually targets just put the canary into TLS area, then there is nothing to spill. Jakub
RE: MIPS maintainership
Hi Catherine, Thank-you for all the advice and guidance while we have been co-maintaining the MIPS backend; it's been a pleasure. Thanks, Matthew From: Moore, Catherine [mailto:catherine_mo...@mentor.com] Sent: 25 April 2018 22:52 To: gcc@gcc.gnu.org Cc: Matthew Fortune Subject: MIPS maintainership Hi all, I need to resign as maintainer for the MIPS port. My work commitments have taken me in a different direction and as a result I haven't been able to actively participate over the last year. I don't see that changing anytime soon. I hope that someone with the interest and the time is available and will volunteer. Thanks, Catherine
Re: Stack protector: leak of guard's address on stack
It's not the canari which is spilled in this case, but the address to the canari. Which means an attacker could make it point to something else than the real canari. On 27 April 2018 at 13:16, Jakub Jelinek wrote: > On Thu, Apr 19, 2018 at 06:17:26PM +0100, Thomas Preudhomme wrote: > > For stack protector to be robust, at no point in time the guard against > > which the canari is compared must be spilled to the stack. This is > achieved > > by having dedicated insn pattern for setting the canari and comparing it > > against the guard which doesn't reflect at RTL what is happening. However > > computing the address of the guard is done using standard movsi pattern > and > > can thus be spilled (see PR85434). I'm reaching out to the community for > > ideas on how to avoid this. > > Usually targets just put the canary into TLS area, then there is nothing to > spill. > > Jakub >
Re: Stack protector: leak of guard's address on stack
On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote: > It's not the canari which is spilled in this case, but the address to the > canari. Which means an attacker could make it point to something else than > the real canari. When the canary is in TLS area, it is usually small constant away from some base register (or segment register) and there is no possibility of having that spilled, the addition is done always in the instruction performing memory read of the canary. Jakub
Re: Stack protector: leak of guard's address on stack
On x86 yes, it's actually done in the same instruction that's doing the comparison if I'm not mistaken. That is not the case for arm and aarch64 though where loading the canari is done separately from the comparison and does not involve an offset. Computing the address from which to do the load is yet again done in a separate instruction. Since these are extra instructions and the address of the canari does not change between the prologue and epilogue, CSE is done on the address (only on arm backend though) and due to register pressure the address is spilled on the stack. On 27 April 2018 at 13:22, Jakub Jelinek wrote: > On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote: > > It's not the canari which is spilled in this case, but the address to the > > canari. Which means an attacker could make it point to something else > than > > the real canari. > > When the canary is in TLS area, it is usually small constant away from some > base register (or segment register) and there is no possibility of having > that spilled, the addition is done always in the instruction performing > memory read of the canary. > > Jakub >
Re: Stack protector: leak of guard's address on stack
On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote: > On x86 yes, it's actually done in the same instruction that's doing the > comparison if I'm not mistaken. That is not the case for arm and aarch64 > though where loading the canari is done separately from the comparison and > does not involve an offset. Computing the address from which to do the load > is yet again done in a separate instruction. Since these are extra > instructions and the address of the canari does not change between the > prologue and epilogue, CSE is done on the address (only on arm backend > though) and due to register pressure the address is spilled on the stack. So just add some UNSPEC around to prevent the CSE (with different number on the prologue and epilogue load, so that the two are considered different). Even when it isn't spilled in the current function, it might be saved and restored in function's it calls and again, an attacker could modify it there. Jakub
Re: Stack protector: leak of guard's address on stack
Yes absolutely, CSE needs to be avoided. I made memory access volatile because the change was easier to do. Also on Arm Thumb-1 computing the guard's address itself takes several loads so had to modify some more patterns. Anyway, regardless of the proper fix, do you have any objection to raising a CVE for that issue? Best regards, Thomas On 27 April 2018 at 14:38, Jakub Jelinek wrote: > On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote: > > On x86 yes, it's actually done in the same instruction that's doing the > > comparison if I'm not mistaken. That is not the case for arm and aarch64 > > though where loading the canari is done separately from the comparison > and > > does not involve an offset. Computing the address from which to do the > load > > is yet again done in a separate instruction. Since these are extra > > instructions and the address of the canari does not change between the > > prologue and epilogue, CSE is done on the address (only on arm backend > > though) and due to register pressure the address is spilled on the stack. > > So just add some UNSPEC around to prevent the CSE (with different number on > the prologue and epilogue load, so that the two are considered > different). Even > when it isn't spilled in the current function, it might be saved and > restored in > function's it calls and again, an attacker could modify it there. > > Jakub >
Second GCC 8.1 Release Candidate available from gcc.gnu.org
The second release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427 and shortly its mirrors. It has been generated from SVN revision 259731. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd.
gcc-8-20180427 is now available
Snapshot gcc-8-20180427 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180427/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 259733 You'll find: gcc-8-20180427.tar.xzComplete GCC SHA256=8016e3aa4b96285742f7382ca53199578e404dcd951ee5777398b99ff2095a3c SHA1=1c1996f08f19bab3eff6ae0a6f6d31ad6713e7e2 Diffs from 8-20180422 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
