RFC: 8139864: Improve handling of stack protection zones.

[Lindenmaier, Goetz]

Hi Coleen, 

> I think your proposal #3 makes sense below.   
Thanks!

> To summarize and to see if
> I have it right, make Stack*Pages be specified as multiples of 4*K size
> pages.
> Is this right? 
Yes.  

>  Were you going to make this change?
I didn't address it yet because the bug was assigned to Gerard.
I'll start work on it today.

Best regards,
  Goetz.


> 
> Thanks,
> Coleen
> 
> 
> On 10/29/15 5:37 AM, Lindenmaier, Goetz wrote:
> > Hi Coleen, Dean,
> >
> > Yes, I can make the change if there is an agreement how to handle it.
> >
> >>   setting 1 may cause customers to get stack overflow SEGVs with normal
> page sizes but so would setting a higher value (like 3).
> > If we use a fixed lower bound, we really should use 1.
> > Using 3 would mean on 64K systems (3+1+1)*64K = 320K of protected area.
> What a waste!
> >
> >> People have suggested adding these parameters, but they seem like
> more work for us.
> > What kind of work do you think of?  Implementing the new flags, or finding
> new settings
> > for already configured applications?  For us, the second is an issue, but we
> still would
> > appreciate a more portable set of flags.
> >
> >>   Plus rounding to page size, you might as well specify the value in pages.
> > The problem is that page size differs from system to system.
> >   * This is not user friendly, as users need to know the page size of their
> system.
> >   * The size of the shadow area depends on frame sizes. These do not vary
> >       from system to system (only from platform to platform).
> >   * Other stack sizes are given in Kbytes.  One combination of flags does
> result
> >       in very different usable stack sizes for the application, at least if you look
> at
> >      the current documentation of the flags (see below).
> >     An example:
> >       ThreadStackSize=512K, Red=1, Yellow=2, Shadow=5
> >      4Kpages:   512K -   32K = 480K usable space -- application runs well
> >      16Kpages: 512K - 128K = 384K usable space -- application gets stack
> overflow
> >      64Kpages: 512K - 512K = 0K      usable space -- application does not start at
> all
> >      This is partially fixed in os coding by adapting the number of
> red/yellow/shadow
> >      pages.  But that is not documented in the flags.
> >      This issue can not be overcome completely, as one page is needed at
> least.
> >   * Other stack sizes are also rounded to page sizes, e.g., see
> os_linux.cpp:4732
> >
> > I think it's a good idea to fix the Red/Yellow/Shadow flags to 4K as Dean
> > proposes.  This makes it portable, easy to document and avoids new flags.
> > In effect, it will halve the protected sizes on systems that have pages > 4K,
> > as currently the sizes are adapted (# pages reduced) on base of 8K page
> size.
> > Further, this effect is reduced by page rounding.
> > Also, it will give applications on systems with >4K who don't set these flags
> > more usable space on the stack without increasing the risk of
> unrecoverable
> > stack overflow in comparison to the 4K system.
> >
> > Best regards,
> >    Goetz.
> >
> >    /* stack parameters */                                                    \
> >    product_pd(intx, StackYellowPages,                                        \
> >            "Number of yellow zone (recoverable overflows) pages")            \
> >            range(MIN_STACK_YELLOW_PAGES,
> (DEFAULT_STACK_YELLOW_PAGES+5))     \
> >                                                                              \
> >    product_pd(intx, StackRedPages,                                           \
> >            "Number of red zone (unrecoverable overflows) pages")             \
> >            range(MIN_STACK_RED_PAGES, (DEFAULT_STACK_RED_PAGES+2))
> \
> >                                                                              \
> >    /* greater stack shadow pages can't generate instruction to bang stack */
> \
> >    product_pd(intx, StackShadowPages,                                        \
> >            "Number of shadow zone (for overflow checking) pages "            \
> >            "this should exceed the depth of the VM and native call stack")   \
> >            range(MIN_STACK_SHADOW_PAGES,
> (DEFAULT_STACK_SHADOW_PAGES+30))    \
> >                                                                              \
> >                                                     \
> >    product_pd(intx, ThreadStackSize,                                         \
> >            "Thread Stack Size (in Kbytes)")                                  \
> >            range(0, max_intx-os::vm_page_size())                             \
> >                                                                              \
> >    product_pd(intx, VMThreadStackSize,                                       \
> >            "Non-Java Thread Stack Size (in Kbytes)")                         \
> >            range(0, max_intx/(1 * K))                                        \
> >                                                                              \
> >    product_pd(intx, CompilerThreadStackSize,                                 \
> >            "Compiler Thread Stack Size (in Kbytes)")                         \
> >            range(0, max_intx)
> >
> >
> >
> >
> > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> > Sent: Mittwoch, 28. Oktober 2015 22:02
> > To: Lindenmaier, Goetz; Gerard Ziemski (gerard.ziemski at oracle.com);
> hotspot-runtime-dev at openjdk.java.net
> > Subject: Re: RFC: 8139864: Improve handling of stack protection zones.
> >
> >
> > On 10/19/15 3:35 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I opened this issue because I think the lower bounds for StackRedPages,
> > StackYellowPages and StackShadowPages introduced in 8078556 cause
> > problems on systems with page sizes > 8K.
> >
> > For a more detailed description of the problems to expect see
> > https://bugs.openjdk.java.net/browse/JDK-8139864.
> >
> > I see a row of possible solutions to this.
> >
> > 1.) Just set the lower bounds to '1'.  That's what I proposed before.
> >      I can imagine setups where one wants to reduce the size of these zones
> to a minimum.
> >      If an application starts a lot of threads, and is known not to overflow
> stacks, this
> >      might be desirable to save memory.
> >
> > Yes, I think 1 would be an acceptable minimum.  It doesn't matter for
> yellow and red pages, but for shadow pages, setting 1 may cause customers
> to get stack overflow SEGVs with normal page sizes but so would setting a
> higher value (like 3).   There really isn't a good minimum so I think 1 might be
> something a customer might want to set so we shouldn't disallow it.
> >
> >
> >
> > 2.) Implement constraint methods that assure the zones never get smaller
> than DEFAULT_STACK_*_PAGES * default_page_size.
> >      This is necessary if you want to make sure the zones never can get
> smaller than that.
> >
> > 3.) Introduce new flags StackRedZoneSize, StackYellowZoneSize and
> StackShadowZoneSize.
> >      Set the default values to those of StackRedPages *4K etc, which is the
> most common page size I guess.
> >      During startup, round these to page size.
> >      Use Stack*ZoneSize in the code.
> >      If Stack*Pages flags are set on the command line, convert them to
> Stack*ZoneSize by multiplying with the
> >      current page size.
> >
> > People have suggested adding these parameters, but they seem like more
> work for us.   Plus rounding to page size, you might as well specify the value
> in pages.   And adding parameters gives us more things to test and maintain.
> >
> > Were you going to make this change?
> >
> > Thanks,
> > Coleen
> >
> >
> >
> >
> > I'm happy to make a webrev for the favored solution.
> >
> > Best regards,
> >    Goetz
> >