New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

Tue May 16 12:53:27 UTC 2023

I have provided cases on the other discussion thread you opened.

On this discussion, I don't like THIS proposal that's been published in 
the last couple of weeks, not 10 years ago. I don't like it for the 
detailed reasons I've given in this thread and I objected to it at the 
first opportunity I have been given. I believe that the majority of the 
JVM community (that have an opinion) agree with me. But I have no idea 
if that is the case - and neither does anyone else apparently. Hence why 
I'm urging this JEP to gain some kind of larger feedback rather than 
just these very niche email lists.

Unlike most JEPs

- this one deprecates a feature (agent attachment works well now with no 
friction, considerable friction is added when the deprecation becomes 
final); most JEPs are a clear enhancement rather than feature deprecation

- this one has been argued against by mutliple people both in these 
email lists and more extensively online; most JEPs have no opposition 
and even struggle to gain notice

To state that the opinion of the community doesn't matter, and that only 
"reports showing that  ... adding a command-line option to allow it is 
onerous", ie that only technical considerations as judged by the 
proposers matter, is a problematic standpoint to take.

On 12/05/2023 16:46, Ron Pressler wrote:
> Let’s start with you describing the particular use-cases of dynamically loaded agents that you’re concerned about and why you think a command-line flag to enable the functionality is onerous. In other words, describe the nature and severity of a *problem*. Remember that the goal of JDK maintainers is to serve the ecosystem as a whole, which means accommodating the conflicting desires by different classes of users. Because different people’s requirements are sometimes in contradiction with one another, we need to make a judgment. As JEP 451 says, this judgment is based on the assumptions that: 1. The need for dynamically loaded agent is not very common, and 2. When needed, adding a flag is not onerous.
>
> Stating you don’t like a policy that’s been discussed for roughly a decade and started to be put into effect five years ago is not enough. However, if you have questions regarding the informational JEP that attempts to summarise past discussions (https://openjdk.org/jeps/8305968) I’ll gladly try and answer them.
>
> — Ron
>
>> On 12 May 2023, at 10:05, Jack Shirazi <jacks at fasterj.com> wrote:
>>
>>
>>> Integrity must be opt out, and cannot be opt in, and so opting in is not a solution that will give us integrity*by default*. Seehttps://openjdk.org/jeps/8305968#Strong-Encapsulation-by-Default
>> This is an opinion, not a statement of fact. It needs to be justified, not assumed. Integrity is a goal, and there is a balance between what is useful and what can be limited. For full integrity, don't use the JVM at all. I for one prefer to continue using it.
>>
>>> The only information of relevance would be reports showing that dynamically loading agents are a commonly-needed functionality and that adding a command-line option to allow it is onerous.
>> I'm fine with that. I'm reporting exactly that here. I encourage others interested in this to also report that. I'll mention it in my next newsletter - where do you want the reports sent? My readers won't want to signup to this email list just to send a comment. At what point does the reporting mean the JEP is dropped?
>>
>>
>> On 12/05/2023 14:44, Ron Pressler wrote:
>>>> On 12 May 2023, at 05:26, Jack Shirazi <jacks at fasterj.com> wrote:
>>>>
>>>> Thank  you for your reply. This makes it clear that the JEP has a single specific tradeoff. So we have two capabilities at issue here
>>>>
>>>> A) Currently libraries can turn themselves into agents
>>>>
>>>> B) Currently agents can remotely attach
>>>>
>>>> The JEP has decided for the community that each of these are a bad thing and should be disabled by default (though enableable by setting an option).
>>> No, the JEP says:
>>>
>>> "To assure integrity, we need stronger measures to prevent the misuse by libraries of dynamically loaded agents. Unfortunately, we have not found a simple and automatic way to distinguish between a serviceability tool that dynamically loads an agent and a library that dynamically loads an agent.”
>>>
>>> The only problem is libraries, but because there’s no simple way to distinguish between the two, and because dynamically loaded agents are not needed in most serviceability uses, disabling them by default is reasonable. BTW, this was already decided in 2017 in JEP 261: https://openjdk.org/jeps/261
>>>
>>> As the JEP also says, in the future we may be able to distinguish between tools and libraries via a more complex mechanism that could allow tools to load agents dynamically without the flag.
>>>
>>>
>>>> My involvement in community discussions over the years has been that no one complains about (A), it has not been used maliciously, and there is a small niche who use it. (B) is used quite a lot and enhances JVM serviceability with a capability that is a clear advantage over other runtimes. It seems a shame to eliminate that competitive advantage.
>>> Malicious use is not a concern *at all*. What this JEP addresses is integrity by default. See https://openjdk.org/jeps/8305968
>>>
>>>> The JEP clearly points out that anyone concerned by these can disable the ability with a simple command-line option, so there is a simple solution for this minority.
>>> Integrity must be opt out, and cannot be opt in, and so opting in is not a solution that will give us integrity *by default*. See https://openjdk.org/jeps/8305968#Strong-Encapsulation-by-Default
>>>
>>>
>>>> The fundamental error is really that the attaching agent is read-write rather than read-only. If we could change that, it would be ideal, but sadly I don't think that's easily doable.
>>> Perhaps, but most uses of dynamically loaded agents (and nearly all uses of dynamically loaded *Java* agents) are for “write.” The most common use-case for “read-only” is dynamically attached advanced profilers that use JVM TI. The solution there, as the JEP says, is not to separate agent capabilities but to improve JFR’s capabilities — which do not require an agent at all — and JFR can obtain profiles far more efficiently than anything JVM TI could ever hope to achieve.
>>>
>>>> I and many in the monitoring community believe this JEP is NOT an enhancement to the JDK. The proposers believe it is. Is there a mechanism other than this email discussion list to gain wider community feedback so we can ascertain if there is really a strong community preference either way?
>>>>
>>> The only information of relevance would be reports showing that dynamically loading agents are a commonly-needed functionality and that adding a command-line option to allow it is onerous.
>>>
>>> — Ron