RFC: 8139864: Improve handling of stack protection zones.

Mon Nov 23 20:17:03 UTC 2015

Hi Goetz,

I think your proposal #3 makes sense below.   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?   Were you going to make this change?

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
>