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

[Alan Snyder]

Interesting discussion.

I’m more worried about JNI. Can you say anything about how you see JNI being restricted?

I use JNI not only to access native services but also to work around bugs or limitations in the JDK using its unrestricted reflection.
As a library developer, I want my library to work on older JDKs, so it is not sufficient to say “it’s been fixed in JDK 33 so you don’t
need to do that anymore”.

Also, I’m wondering whether the end point of this “arms race” will be that libraries declare the superpowers they need and build
tools automatically insert the required command line arguments. That would defeat the purpose, would it not?

  Alan



> On May 14, 2023, at 4:25 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 12 May 2023, at 18:01, Kirk Pepperdine <kirk.pepperdine at gmail.com> wrote:
>> 
>> Hi Ron,
>> 
>> I’m trying to work through some confusion and past 3 levels of discomfort. The confusion is, the JEP talks about code integrity and that agents (both directly and dynamically attached) have the ability to alter loaded code. That the JEP paints the capability in a “bad light” is judgmental which is unfortunate. The ability to alter loaded code is a feature and how that is judged is based on the context on which you look at it. As with all capabilities, it’s a two edged sword. The question I have is, is the harm caused by the feature greater than the benefits. IME the answer is no, the benefits have always widely out-weighed the potential harm.
>> 
> 
> I think the JEP agrees with you. I don’t think it paints code modification in a bad light at all, but, rather, points out that it’s a useful but advanced and dangerous capability — which it is — and so should be handled with care. If you can point to where you feel the capability is presented as bad rather than dangerous perhaps we can change the wording.
> 
>> My confusion is, what does the ability to alter loaded code have to do with wither or not an agent has been loaded directly or dynamically. The agent still has the ability (today) to alter code. If the goal is to take away an agent’s ability to alter code in the runtime, then what this have  to do with how the agent has been loaded. What am I missing?
> 
> Perhaps you’re missing the background on “integrity by default” in this informational JEP: https://openjdk.org/jeps/8305968
> 
> The policy is that superpowered capabilities that work beyond encapsulation boundaries must be explicitly authorised by the application, and must not be silently used by libraries. Loading an agent at startup (or adding the -XX:+EnableDynamicAgentLoadingFlag) is the application saying “I’m authorising the use of this superpower”. Without it, libraries today use the dynamic agent loading capability — but not the capability to load agents at startup — to grant themselves the superpower to change the meaning of any line of code in the application *without the application’s knowledge/consent*.
> 
>> Also, that a feature might cause harm isn’t a reason to lock it down or take it away.
> 
> We’re not removing any feature here. Integrity by default merely requires the application’s approval for certain superpowers. The informational JEP explains why integrity by default is a very good reason to do that.
> 
>> Yes, there was immense pressure in JDK 6 (and even earlier) to add more observability. Have those pressures changed since that release? Or, have we learned something that is enabling the release of something better? It not, the what is it that is really happening here? Again, I’m confused.
> 
> The issue isn’t observability at all. It’s the use of the dynamic agent loading capability *by libraries* to grant themselves superpowers without the application’s knowledge. Unfortunately, we cannot distinguish between use of the capability by observability tools (which is completely legitimate) and use by libraries (which is not). We believe that requiring the explicit authorisation will not have much of an effect on observability because most observability uses either don’t require agents at all (BTW, the addition of JFR in JDK 11 helped with that) or can use agents loaded at startup.
> 
>> 
>> My second level of discomfort is that this is happening in an LTS release. Yes, I know, a LTS is not suppose to be different than a non-LTS but that’s not how our customers are treating LTS releases so it behoves us to take this into account.
> 
> That too many Java users misunderstand various LTS offerings is unfortunate, but we have taken into account the fact that more people will adopt 21 than 20, which is why the JEP now merely talks about a warning, not disabling dynamic agent loading by default. A release that is expected to be popular is a great time to introduce a warning, as that will educate many users. If we added a warning in 22 and disabled the mechanism by default in 23, those who (unfortunately) choose to skip those versions may be surprised.
> 
>> 
>> My third level of discomfort comes from not knowing the full impact of this change. I keep asking if anyone knows and I’ve yet to see a reply.
> 
> The warning will hopefully let us know if our analysis in the JEP is wrong. Again, this JEP merely adds a warning.
> 
>> My apologies if someone has answered and I’ve missed it. Having a survey in this mailing list feels very narrow as it’s not likely to be seen by even a fraction of 1% of java developers. I spoke to some of the PM’s as MS as well as the people working on ApplicationInsights. I didn’t get a good sense from the PM as to what the potential impact of this change might be. The AI group uses dynamic attach to inject this monitoring tooling into the loaded application. The AI group said they could adjust to this change but that would be by turning on this feature for every single JVM using AI that is running in Azure.
> 
> Why can’t they load their tooling agent at startup?
> 
>> I’m not sure that I see the benefit to anyone in further cluttering the command line. 
> 
> 1. The assumption is that most applications and tools will not suffer significantly, and this JEP will help us make sure that is the case.
> 
> 2. The Java runtime has a lot of configuration options and and they’re all controlled from the command line or  “@files”.  Mere additional clutter in the runtime's configuration for a minority of applications is not, in itself, sufficient to offset the importance of integrity by default, but if there are more severe problems, we’d like to hear about them.
> 
> — Ron