JEP411: Missing use-case: Monitoring / restricting libraries

[Chris Hegarty]

On 28 Apr 2021, at 11:38, Markus Gronlund <markus.gronlund at oracle.com<mailto:markus.gronlund at oracle.com>> wrote:

Hi Lim,

JFR specific feedback can be posted to: hotspot-jfr-dev at openjdk.java.net<mailto:hotspot-jfr-dev at openjdk.java.net>

Thanks Markus. That is the appropriate list to send JFR feedback.

Just to add, I filed an Enhancement Request in JIRA, 8265962: "Evaluate adding Networking JFR events” [1], to track the possibility of adding JFR events to the JDK libraries that perform low-level networking activity (which is mostly in the purview of the networking and libraries area). If we had such, then it would be possible to monitor *all* low-level network activity performed by the platform, regardless of which higher-level library is performing the activity. Clearly such would not capture URLs, but rather the network activity that would be triggered by, say, an HTTP Client library. This seems like a more fruitful and uniform approach, rather than trying to add JFR events to, say, every HTTP library.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8265962


Thanks
Markus

-----Original Message-----
From: Lim <lim.chainz11+mailing at gmail.com<mailto:lim.chainz11+mailing at gmail.com>>
Sent: den 28 april 2021 12:18
To: Markus Gronlund <markus.gronlund at oracle.com<mailto:markus.gronlund at oracle.com>>
Cc: Ron Pressler <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>>; security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>
Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries

Hi Markus, thank you for giving me the guidance for performing the JFR programmatically.
I am able to test if my use case is suitable. Where do I provide my feedback/issue of using the streamed JFR?

On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund <markus.gronlund at oracle.com<mailto:markus.gronlund at oracle.com>> wrote:
If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event.

I understand that new events can be added in code that I have control of using the Events API but in this case, which is the name of URLs is not feasible.

Firstly, using a Java agent to instrument bytecode cannot be scaled because there are a lot of HTTP libraries, including the built in Java APIs and 3rd parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP wrapper" if the author doesn't want dependency. In addition, these 3rd party libraries can be shaded and relocated, making it harder to target via instrumentation.

Obfuscation can also have an impact on reliability of instrumentation, since obfuscation can be changed in every version and what if the obfuscation has "anti-tamper/anti-debug" features? This is not scalable if we need to monitor for each library that might call URLs.

If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events.

I believe that the majority of the HTTP libraries, and code that roll their own are using the built in Java APIs, thus monitoring the built in API that is used for making URLs calls make sense. Then, it can be scaled to most of the libraries compared to instrumenting each one which has its own problem stated above.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210428/0ef6571a/attachment.htm>