Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

2017-07-24 Thread Jeff Law
On 07/21/2017 12:17 PM, Wilco Dijkstra wrote: > Jeff Law wrote: > >> Examples please? We should be probing the outgoing args at the probe >> interval once the total static frame is greater than 3k. The dynamic >> space should be probed by generic code. > > OK, here are a few simple example

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

2017-07-21 Thread Wilco Dijkstra
Jeff Law wrote:   > Examples please?  We should be probing the outgoing args at the probe > interval  once the total static frame is greater than 3k.  The dynamic > space should be probed by generic code. OK, here are a few simple examples that enable a successful jump of the stack guard despit

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

2017-07-19 Thread Jeff Law
On 07/19/2017 11:53 AM, Wilco Dijkstra wrote: > Hi Jeff, > > There is an issue with your AArch64 patch, it fails to apply properly and does > so silently using 'patch'. I also noticed some odd control characters in the > other > patches, but they didn't appear to fail (or at least everything buil

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

2017-07-19 Thread Wilco Dijkstra
Hi Jeff, There is an issue with your AArch64 patch, it fails to apply properly and does so silently using 'patch'. I also noticed some odd control characters in the other patches, but they didn't appear to fail (or at least everything builds). Anyway with -Ofast -static the overall codesize incr

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Jeff Law
On 07/17/2017 04:42 PM, Wilco Dijkstra wrote: > Jeff Law wrote: >> On 07/17/2017 05:27 AM, Wilco Dijkstra wrote: > >>> A minimum guard size of 64KB seems reasonable even on systems with >>> 4KB pages. However whatever the chosen guard size, you cannot defend >>> against hostile code. An OS can

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Wilco Dijkstra
Jeff Law wrote:  > On 07/17/2017 05:27 AM, Wilco Dijkstra wrote: > > A minimum guard size of 64KB seems reasonable even on systems with > > 4KB pages. However whatever the chosen guard size, you cannot defend > > against hostile code. An OS can of course increase the guard size well > > beyond

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Trevor Saunders
On Mon, Jul 17, 2017 at 09:51:40AM -0600, Jeff Law wrote: > On 07/16/2017 12:36 PM, Trevor Saunders wrote: > >>> On the other hand if probing is fast enough that it can be on by default > >>> in gcc there should be much less of it. Even if you did change the ABI > >>> to require probing it seems u

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Jeff Law
On 07/16/2017 12:36 PM, Trevor Saunders wrote: >>> On the other hand if probing is fast enough that it can be on by default >>> in gcc there should be much less of it. Even if you did change the ABI >>> to require probing it seems unlikely that code violating that >>> requirement would hit problem

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Jakub Jelinek
On Mon, Jul 17, 2017 at 09:24:27AM -0600, Jeff Law wrote: > >> While I'm not really comfortable with the 2k/2k split in general, I > >> think I can support it from a Red Hat point of view -- largely because > >> we use 64k pages in RHEL. So our guard is actually 64k. Having a > >> hostile call ch

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Jeff Law
On 07/17/2017 05:27 AM, Wilco Dijkstra wrote: > Jeff Law wrote: > >> So would a half-half (2k caller/2k callee) split like Florian has >> proposed work for you? ie, we simply declare a caller that pushes the >> stack pointer 2k or more into the guard as broken? > > My results show using a 4KB gu

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-17 Thread Wilco Dijkstra
Jeff Law wrote: > So would a half-half (2k caller/2k callee) split like Florian has > proposed work for you?  ie, we simply declare a caller that pushes the > stack pointer 2k or more into the guard as broken? My results show using a 4KB guard size is not ideal. 2KB of outgoing args is too large

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-16 Thread Trevor Saunders
On Wed, Jul 12, 2017 at 03:08:28PM -0600, Jeff Law wrote: > On 07/12/2017 06:47 AM, Trevor Saunders wrote: > > On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote: > >> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: > >>> Jeff Law wrote: > aarch64 is the first target that does not have any

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-14 Thread Wilco Dijkstra
Jakub Jelinek wrote: > On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote: > > Therefore even when using a tiny 4K probe size we can safely adjust SP by > > 3KB > > before needing an explicit probe - now only 0.6% of functions need a probe. > > If we choose a proper minimum probe dist

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-14 Thread Jakub Jelinek
On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote: > No - like I mentioned before that's not correct nor acceptable as it would > imply > that ~70% of functions need a probe at entry. I did a quick run across SPEC > and > found the outgoing argument size is > 1024 in just 9 functions

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-13 Thread Jeff Law
On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: > Jeff Law wrote: >> aarch64 is the first target that does not have any implicit probes in >> the caller. Thus at prologue entry it must make conservative >> assumptions about the offset of the most recent probed address relative >> to the stack pointe

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-12 Thread Jeff Law
On 07/12/2017 06:47 AM, Trevor Saunders wrote: > On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote: >> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: >>> Jeff Law wrote: aarch64 is the first target that does not have any implicit probes in the caller. Thus at prologue entry it must

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-12 Thread Trevor Saunders
On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote: > On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: > > Jeff Law wrote: > >> aarch64 is the first target that does not have any implicit probes in > >> the caller. Thus at prologue entry it must make conservative > >> assumptions about the offs

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

2017-07-11 Thread Jeff Law
On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: > Jeff Law wrote: >> aarch64 is the first target that does not have any implicit probes in >> the caller. Thus at prologue entry it must make conservative >> assumptions about the offset of the most recent probed address relative >> to the stack pointe