Explicitly tell Netty to not use unsafe

[jasontedor]

With the security permissions that we grant to Netty, Netty can not
access unsafe (because it relies on having the runtime permission
accessDeclaredMembers and the reflect permission
suppressAccessChecks). Instead, we should just explicitly tell Netty to
not use unsafe. This commit adds a flag to the default jvm.options to
tell Netty to not look for unsafe.

Relates #19562, relates netty/netty#5624

[jasontedor]

Additionally, Netty looking for and not being able to access unsafe leads to log messages that might be scary to the end-user on startup:

[2016-08-03 12:59:34,765][INFO ][io.netty.util.internal.PlatformDependent] Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to avoid potential system unsuitability.

I've opened netty/netty#5624 to not log this message when unsafe is explicitly disabled, as we are configuring with this PR.

[dakrone]

LGTM

[Scottmitch]

no unsafe 😢

Out of curiosity ... do you guys have perf benchmarks you can report with and without unsafe to understand the impacts of unsafe?

[s1monw]

@Scottmitch that is actually a good thing. I am so happy we don't allow it to do that. Also it's not a regression it's been like this since 2.0 I guess

[Scottmitch]

my assumption is that performance is traded for safety/security/isolation/etc... this why I'm curious to see if benchmarking is available to confirm this suspicion.

I'm not familiar with elastic and just followed this from a Netty issue ... I'm not claiming its a regression, good/bad in this context, and didn't mean to hijack the thread ... just curious :)

[jasontedor]

@Scottmitch I tested the performance difference (after granting a lot of scary permissions 😇). For the performance metrics that we care about (indexing throughput, query latency, GC metrics, etc.), the benchmarks with unsafe were inline with the benchmarks with no unsafe, effectively no difference at all. For us, using unsafe provides zero benefit but has a huge cost.

I did notice when I ran these benchmarks that there are several places where executing the privileged code is not handled properly within Netty. I'll open a PR against Netty to address.

[Scottmitch]

@jasontedor - thanks for following up ... looking forward to your PR :)

[jasontedor]

@Scottmitch I opened netty/netty#5640 and netty/netty#5641.

[slovdahl]

Sorry for being a little bit late to the party, but do you have pointers to specific issues caused by letting netty use sun.misc.Unsafe? I'm wondering because I have another transitive dependency on netty in my environment that seems to depend on having a working sun.misc.Unsafe.

[slovdahl]

I was a bit unclear in my previous post. For clarification: my question is just related to the transport client, and not a complete ES node.