JEP draft: Disallow the Dynamic Loading of Agents by Default

[Ron Pressler]

Hi Volker!

> On 28 Apr 2023, at 16:38, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I think it is a little unfortunate to put the usage of s.m.Unsafe and
> JNI/Instrumentation/JVMTI into the same category, especially when it
> comes to blaming developers for their usage. While s.m.Unsafe has
> always been an internal, undocumented and unsupported API, the latter
> three are part of the Java Platform (e.g. "native" is a Java keyword
> and Runtime.loadLibrary() is part of the Java API).

To have integrity by default, theses must all become restricted. In fact — not just them. Even the fully-official and brand-new FFM API, that a lot of investment has gone into very recently, must also be restricted. 

That these features must be restricted doesn’t mean they’re wrong or bad. It just means that they're superpowers, and so the user must acknowledge the choice to use them over the loss of integrity. Native libraries are good and integrity is good, but because they’re in contradiction, there must be a switch expressing the user’s preference like other switches offered by the runtime to select between alternatives.

Unsafe, on the other hand, may become more than just restricted over time. It may gradually be emptied out until it’s gone.

> 
> Do you really plan to make JNI an optional feature which will have to
> be manually enabled at startup?

Not optional at all, but an important, useful feature that is restricted; JNI’s replacement, FFM will be restricted, too (in its use of native libraries). The restriction of FFM is already mentioned in JEP 442. Another JEP addressing JNI will be published soonish.

> What will be the benefit?

Integrity. The ability to to bypass encapsulation when needed is not being taken away, but we need the new ability to establish and enforce invariants. We don’t yet have it.

> I understand
> that in an ideal world where you had no user-supplied JNI libraries at
> all, you might be able to perform more/better optimizations. But as
> you'd have to support JNI anyway, wouldn't the maintenance of the
> resulting code become a nightmare. How many "if (JNI) {..} else {..}"
> would we get?

There’s no need for such code. Modules that need JNI will use JNI. The application will simply give them permission to do so with --enable-native-access=MODULE-NAME, as it would also do to allow FFM to use native libraries.

> And what would be the benefit of disabling it by default
> for the user except increased "integrity"?

Not disabled, restricted, and integrity is the benefit for the user, e.g. in the form of programs not breaking (or breaking less) when upgrading the JDK. Integrity is required for the platform to continue evolve while keeping the ecosystem sustainable.

> I.e. do you have some
> concrete examples of planned features X, Y, Z which will only work
> with disabled JNI?

Not disabled, restricted. Like all encapsulation-breaking restricted superpowers, allowing them might have implications on possible Leyden features. For example, if a private method could be accessed from outside a module — whether through deep reflection or JNI — private methods could not be removed at link time.

> Will these features be Java SE features or
> implementation specific OpenJDK-only features?

As with all integrity and strong encapsulation features, all limitations will be part of the platform spec.

We realise that in each individual case there might be good reasons to allow knocking down encapsulation barriers. But whereas every application and library author rightfully want minimise the burden on their particular code, such individual decisions inevitably lead to a tragedy of the commons (as they already have). We must strive to minimise the overall burden integrated over the entire ecosystem *as a whole*. So the platform will have the right defaults for the ecosystem, and every application would be able to relax encapsulation to suit its particular needs.

Most Java program don’t use native libraries, agents (startup or dynamic), or deep reflection. Many do, and these features are very powerful and can be very useful, but with great power comes great responsibility, and that responsibility falls on the *application*. Libraries must not silently impose that responsibility on the application in a way that makes it infeasible to exercise.

Moreover, most encapsulation boundaries are never bypassed, but without integrity by default, the platform and its users still can’t be certain that code means what it says as long as any fourth-level dependency can decide on its own that any line of code in the program might mean something else.

> 
> I don't think it is fair to assume that profilers are the only "valid"
> use case for agents and imply that all other use cases are a mis-use
> of the API.

We are not assuming that at all. Only the use of *dynamically loaded* agents *by libraries* is misuse. Dynamically loaded agents were specifically designed to support serviceability tools, not to allow libraries to circumvent the need to ask the application for permission to break encapsulation.

> 
> I don't understand this "Non-Goal"? The Attach API [1] allows to
> dynamically attach to a running JVM and "Once a reference to a virtual
> machine is obtained, the loadAgent, loadAgentLibrary, and
> loadAgentPath methods are used to load agents into target virtual
> machine". So how can you achieve this JEP's goals without
> changing/restricting the Attach API? I therefore think this "Non-Goal"
> should be rephrased to explain which parts of the Attach API will be
> changed and moved to the "Goal" section instead.

It says “for monitoring and management purposes.” These purposes don’t require dynamically loaded agents. They rarely require agents at all, but when they do, they only need agents loaded at startup.

> 
> General comments:
> 
> - You go into great detail to explain why a human-operated tool is
> "superior" (in the sense of trust and security) to a library and
> "would ideally not be subject to the integrity constraints imposed on
> the application". I can't follow this argument, because both, the
> decision to use a specific tool as well as the decision to rely on a
> library is taken by a human.

A tool is not superior. Only:

1. Most libraries that break encapsulation are not chosen by application authors. They are usually low-level libraries chosen by the authors of the libraries that the application uses, i.e. they’re transitive dependencies. I don’t think that applications in the JDK 8 timeframe became non-portable as a result of a conscious choice. Moreover, it is practically infeasible to actually know everything the code you use may do even if you want to. So not only do application authors not know what libraries do (especially deep dependencies), but they *can’t* feasibly know.

2. You expect a mechanic to tune your car engine but you'd probably be surprised to learn that the little tree air freshener climbs down from the rearview mirror at night and crawls into the engine to make modifications. When an operator uses a serviceability tool, they expect it to open up the box and rummage through internals. That’s what servicing often means, in software as in the physical world. They do not expect that of libraries.


> I'd even argue that the decision to
> depend on a specific library which requires the dynmaic attach
> mechanism is taken by a more knowledgeable user (i.e. the developer
> himself). Of course both, a tool as well as a library can contain
> malicious code, but I don't see a fundamental difference between the
> two.

Malicious code is not a concern at all; we assume all code — whether in tools or libraries — is trusted and benevolent. (Even when looking at the security aspect in the server side ecosystem overall, malicious code amounts to a minuscule portion of the danger, judging by the number of attacks. When it comes to server security, benevolent code poses a much greater risk than malicious code, as the vast majority of security attacks exploit vulnerabilities in benevolent, trusted code. Of course, benevolent code imposes other risks covered in the JEP that are unrelated to security). 

Knowledgeable users who want to allow a library to arbitrarily change the meaning of code in the application are free to give it the permission to do so. But too many applications don’t even know that a dependency of a dependency of a dependency of theirs does it, and so the permission to do it cannot be the default.

> 
> - You may argue that users have to be protected from malicious
> libraries which gain their superpowers by secretly loading agents at
> runtime.

Again, malicious code is largely a non-issue for Java since Applets were removed.

Since you brought up malicious code in previous conversations, too, let me repeat that again: Even though there have been some software supply chain attacks on various language ecosystems, malicious code poses a relatively small risk to Java nowadays and it is *not* a major concern (at least for the moment); most risks — including security risks — are due to nice, helpful code.

> But users who don't know and don't care about their library
> dependencies will just as easy and without reflection (pun intended :)
> add the -XX:+EnableDynamicAgentLoading to their command line arguments
> (making this the new, most often used command line option even
> surpassing the usage of --add-opens :)

Adding permissions by “cargo cult” is, indeed, a problem, but at the very least the command line would still offer an auditable record of the risks taken up by the application. Responsible companies know that in some situations they may be held accountable for their technical decisions and deviations from recommended practices, and will have mechanisms in place to review command-line permissions just as they review code.

As a general rule, while we certainly want to help users do the right thing, we must first give those who want to do the right thing the ability to do so. Without strengthening strong encapsulation, even someone who really wants to know the integrity risks is unable to do so without an infeasible analysis of ever line of code in the application and all of its dependencies.

Moreover, because quite a few application authors do want to carefully consider risks, the fact that they need to explicitly accept more risk to use certain libraries would put pressure on libraries to reduce their superpower demands.

> 
> - I still can't understand the benefit of "only" changing the default
> behavior for dynamic agent loading. I could understand this if you'd
> do it with a plan to deprecate and completely remove the dynamic agent
> loading capability. But what are the benefits of changing the default
> if you'll have to support the functionality anyway?

The application can choose to knock down encapsulation barriers as it wishes (after all, it can even modify the Java runtime as it controls it), but we want the command line to offer a map of the codebase and its abilities. You get integrity by default, and an auditable record of the encapsulation choices always. We want tools to have superpowers, and it’s even arguably okay for certain libraries to be granted superpowers in certain situations provided that it’s done with the application’s explicit consent. It’s just that the situation where superpowers are given silently and by default has become untenable for the ecosystem as a whole.

> As mentioned in
> earlier discussions, my main concern with the proposed change is the
> impact it will have on the evolution of Java. Java's dynamic features
> are one of its biggest strength and a major reason for its success.

That’s right, but the Why Now? section covers that in detail. In short, the times — they are a changin’, and Java must be a changin’ with them. Even putting aside the new requirements and more Java-in-Java, the old situation has become untenable as we saw in the 8 -> 9+ migration. The reason the old way worked — until it didn’t — was that for a long while (the 6-8 timeframe) Java was relatively stagnant.

However, that relative stagnation didn’t just allow the encapsulation free-for-all to work; it’s also what made much of it necessary in the first place, to work around shortcomings in the JDK’s development. So not only can we not continue with the old regime, but there’s not as much need for it anymore.

However useful dynamism is at times, we must have the ability to control it. The faster Java evolves, the more important that control becomes. The most important thing to remember is that the need for integrity doesn’t come from some theoretical desire for architectural cleanliness, but from real user needs. Users want smoother upgrades; they want robust security; they want more features, and they want new kinds of features that reduce startup time. All these things require control over Java’s dynamism. Some users may want dynamism, too, but since these desires are in conflict, applications must choose between them, and that’s the idea of integrity by default (dynamism by default and integrity by choice can’t work because of the structure of the Java ecosystem).

> Sacrificing some of them or making their usage increasingly expensive
> requires a broader discussion in the community and shouldn't happen
> "under the hood" of a discussion about the default setting of a
> command line flag.

First, while requiring an auditable map of the codebase certainly does require some effort, let’s not exaggerate it. We’re talking about cost that is negligible compared to that of developing software, cost that is imposed only on those who want or need to use relatively advanced superpowered features, and cost that results in a something of value: a map of the codebase and its permissions. But yes, some will be inconvenienced by this, but so are those who cannot easily upgrade JDK versions due to non-portable libraries. You can call it a sacrifice if you wish, but whatever we do or don’t do *someone’s* convenience will be sacrificed, and this direction reduces rather than increases the overall sacrifice. That’s exactly why this is the direction — we want to reduce the overall pain for users and increase their value.

Second, that lengthy discussion about this direction already took place over years when Jigsaw was under development (as did the discussion about agents in particular). What was missing was a summary in JEP form, hence the informational JEP. We’ll post the JEP to jdk-dev once we finish writing it, but it describes a path that Java has already been on for several years.

> 
> - I don't understand why this JEP has scope "SE". As you rightly
> mentioned, the Attach API is a "non-standard" API which can be changed
> at any time and without affecting the Java SE specification, so this
> JEP should rather have scope "JDK" instead. On the other hand, the
> fact that this functionality is not governed by the SE specification
> will allow different OpenJDK distributors to use a different default
> setting for -XX:EnableDynamicAgentLoading which has the potential to
> cause a lot of confusion if we can't sattle on a common strategy.

The Attach API is JDK-specific, but agents are an SE feature (well JVM TI is optional), and the platform spec will say something along the lines of “if an implementation offers a way to attach an agent to a running JVM instance, that capability must be disabled by default and enabled with an explicit flag”.

> 
> - If doing this change at all, I think it would be better to do it in
> a non-LTS release first.

LTS is a service governed by Oracle Sales or something like that on the business side of things. OpenJDK has no concept of LTS. Nevertheless, given that for various business reasons more people are likely to be using JDK 21 than other versions, we can take that expected popularity into account. See my reply to Dan.

— Ron