Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Chris Hegarty]

Hi,

I've read all the messages in this thread, and want to offer a somewhat 
different perspective. I'm biased since I spend quite a bit of my time 
working on Elasticsearch these days, which is an application, so I'm 
technically "the user". We experimented with and provided feedback on 
the FFM API several times over the years. As part of that, we evaluated 
and have a positive view of the restrictions on native access.

Elasticsearch directly and indirectly leverages natives; directly from 
JNA, and indirectly as we use Netty. Our plan and previous experiments 
have been to replace our use of JNA with the FFM API. Given our 
particular usage, we're not overly concerned with performance (though 
our experiments showed that the FFM API way outperforms JNA), but rather 
the benefits of the native access restrictions. The core of the 
Elasticsearch platform is modularized, and as such we'll limit native 
access to just the modules that need it. Additionally, we'll use 
`ModuleLayer.Controller.enableNativeAccess` to grant access to JNI from 
Netty, as we load Netty in a child layer of the boot layer.

FWIW, I like the alignment JNI and the FFM API, in this respect. Both 
old and new are treated in a similar way.

Again, I'm "the user" and Elasticsearch already starts from a script, so 
adding `--enable-native-access=M` is not a big deal. What is important 
for us is that the warnings are suppressible - which they are in this 
particular case. In fact, all warnings should be suppressible by the 
user, which is not currently the case, but that is orthogonal.

I want to highlight one specific use case. We use JNA during the startup 
of the server to do configuration and setup-like things. The most 
significant being to install system call filters, that among other 
things, block process execution, e.g. through seccomp on Linux. 
Elasticsearch currently runs with a restrictive security manager 
installed, and the use of system call filtering is one particular 
mitigation (along with static analysis and byte code instrumentation), 
that will be required once the security manager is removed. I don't 
think this use case identifies a fundamental design issue with this JEP, 
but seems a little counterintuitive - the enablement of inherently 
dangerous native access to enable process-level restrictions. However, 
the future actual restrictions and the auditability of native usage are 
very much welcome.

-Chris.

On 04/09/2023 07:49, Alan Bateman wrote:
> On 01/09/2023 22:16, Attila Kelemen wrote:
>> :
>>
>> When I wrote "stop using the module system" I'm obviously talking 
>> about the application itself being modular. I would have expected 
>> that you also believe that it would be better, if applications were 
>> modular. Given that I assumed from what you wrote that you regret the 
>> fact that modules were not added on day 1 (in which case there would 
>> only be modular apps most likely). Yet, this JEP just motivates 
>> people away from modules.
>
> I don't think this is the case. Instead I think there is a lot of 
> potential for a much better story. Modules lend themselves to doing a 
> lot more at build time and setting things up for simple/fast checks at 
> startup (think post resolution checks). It's not hard to think about 
> fail fast if a module requires the "restricted methods or native code" 
> capability that has not been granted. Combing a set of modules at link 
> time also has a potentially interesting story when using jlink to 
> create an application that has an initial/main module. In that case, 
> you can think about checking capabilities (or whatever term is 
> introduced) at build/link time.
>
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230905/76d1201c/attachment.htm>