<html><body><div dir="ltr"><div style="">

    </div><div style=""><div>

        <div dir="ltr">Hello,</div><div dir="ltr"><br></div><div dir="ltr">Want to mention another point. In the past there has been a tendency of JRE to hide internal implementations. That’s somewhat understandable, however it was always a convinience to be able to poke at internals. I mean it took so long to offer a API for base64, or being able to actually create self signed certificates or parse CRLs, or to extend JSSE. With the stronger encapsulation this will now become a no go, making it more important for more official APIs - for example how to access the Top Level Domain List - I could probably give more examples. The JEP could acknowledge this.</div><div dir="ltr"><br></div><div dir="ltr">Gruss</div><div dir="ltr">Bernd</div><div id="ms-outlook-mobile-signature"><div style="direction:ltr">-- </div><div style="direction:ltr">http://bernd.eckenfels.net</div></div>

    </div>

<div> </div><hr style="display:inline-block;width:98%" tabindex="-1"><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>Von:</b> serviceability-dev <serviceability-dev-retn@openjdk.org> im Auftrag von Volker Simonis <volker.simonis@gmail.com><br><b>Gesendet:</b> Freitag, April 28, 2023 5:39 PM<br><b>An:</b> Ron Pressler <ronpressler@oracle.com><br><b>Cc:</b> jigsaw-dev@openjdk.org <jigsaw-dev@openjdk.org>; serviceability-dev@openjdk.org <serviceability-dev@openjdk.org><br><b>Betreff:</b> Re: JEP draft: Disallow the Dynamic Loading of Agents by Default<div> </div></font></div>On Wed, Apr 19, 2023 at 12:29 AM Ron Pressler <ron.pressler@oracle.com> wrote:

<br>>

<br>> Hi.

<br>>

<br>> Following last month’s email about changing the default of

> EnableDynamicAgentLoading [1], we’ve now published two JEP drafts.

<br>>

<br>> The first is an informational JEP describing what integrity is and why we need it,

<br>> and motivates what changes are required to get it (which include the

<br>> restriction of dynamically loaded agents among others):

<br>>

<br>> https://openjdk.org/jeps/8305968 Integrity and Strong Encapsulation

<br>>

<br>

>    - Use sun.misc.Unsafe to access and modify private fields.

<br>>

<br>>    - Load a native library that employs JNI to call private methods and

<br>>      set private fields. (The JNI API is not subject to access checks.)

<br>>

<br>>    - Load an agent that changes code in a running application,

>      using an API intended for tools only.

<br>>

<br>>   To attain our goal of integrity by default, we will gradually restrict

<br>>   these APIs and close all loopholes in a series of upcoming JEPs, ensuring

>   that no library can assume superpowers without the application's consent.

<br>>   Libraries that rely on these APIs should spend the time remaining until

>   they are restricted to prepare their users for any necessary changes.

<br>

<br>I think it is a little unfortunate to put the usage of s.m.Unsafe and

<br>JNI/Instrumentation/JVMTI into the same category, especially when it

<br>comes to blaming developers for their usage. While s.m.Unsafe has

<br>always been an internal, undocumented and unsupported API, the latter

<br>three are part of the Java Platform (e.g. "native" is a Java keyword

and Runtime.loadLibrary() is part of the Java API).

<br>

<br>Do you really plan to make JNI an optional feature which will have to

<br>be manually enabled at startup? What will be the benefit? I understand

<br>that in an ideal world where you had no user-supplied JNI libraries at

<br>all, you might be able to perform more/better optimizations. But as

<br>you'd have to support JNI anyway, wouldn't the maintenance of the

<br>resulting code become a nightmare. How many "if (JNI) {..} else {..}"

<br>would we get? And what would be the benefit of disabling it by default

<br>for the user except increased "integrity"? I.e. do you have some

<br>concrete examples of planned features X, Y, Z which will only work

<br>with disabled JNI? Will these features be Java SE features or

implementation specific OpenJDK-only features?

<br>

<br>> The second touches on the specifics of dynamically loaded agents and the

<br>> proposed change:

<br>>

<br>> https://openjdk.org/jeps/8306275 Disallow the Dynamic Loading of Agents by Default

<br>>

<br>

<br>>    Agents are used by profiling tools to instrument Java applications,

<br>>    but agents can also be misused to undermine the integrity of the

<br>>    Java Platform.

<br>

<br>I don't think it is fair to assume that profilers are the only "valid"

<br>use case for agents and imply that all other use cases are a mis-use

of the API.

<br>

<br>>    - It is not a goal to change the Attach API that allows a tool to

>      connect to a running JVM for monitoring and management purposes.

<br>

<br>I don't understand this "Non-Goal"? The Attach API [1] allows to

<br>dynamically attach to a running JVM and "Once a reference to a virtual

<br>machine is obtained, the loadAgent, loadAgentLibrary, and

<br>loadAgentPath methods are used to load agents into target virtual

<br>machine". So how can you achieve this JEP's goals without

<br>changing/restricting the Attach API? I therefore think this "Non-Goal"

<br>should be rephrased to explain which parts of the Attach API will be

changed and moved to the "Goal" section instead.

<br>

<br>General comments:

<br>

<br>- You go into great detail to explain why a human-operated tool is

<br>"superior" (in the sense of trust and security) to a library and

<br>"would ideally not be subject to the integrity constraints imposed on

<br>the application". I can't follow this argument, because both, the

<br>decision to use a specific tool as well as the decision to rely on a

<br>library is taken by a human. I'd even argue that the decision to

<br>depend on a specific library which requires the dynmaic attach

<br>mechanism is taken by a more knowledgeable user (i.e. the developer

<br>himself). Of course both, a tool as well as a library can contain

<br>malicious code, but I don't see a fundamental difference between the

two.

<br>

<br>- You may argue that users have to be protected from malicious

<br>libraries which gain their superpowers by secretly loading agents at

<br>runtime. But users who don't know and don't care about their library

<br>dependencies will just as easy and without reflection (pun intended :)

<br>add the -XX:+EnableDynamicAgentLoading to their command line arguments

<br>(making this the new, most often used command line option even

<br>surpassing the usage of --add-opens :)

<br>

<br>- I still can't understand the benefit of "only" changing the default

<br>behavior for dynamic agent loading. I could understand this if you'd

<br>do it with a plan to deprecate and completely remove the dynamic agent

<br>loading capability. But what are the benefits of changing the default

<br>if you'll have to support the functionality anyway? As mentioned in

<br>earlier discussions, my main concern with the proposed change is the

<br>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.

<br>Sacrificing some of them or making their usage increasingly expensive

<br>requires a broader discussion in the community and shouldn't happen

<br>"under the hood" of a discussion about the default setting of a

command line flag.

<br>

<br>- I don't understand why this JEP has scope "SE". As you rightly

<br>mentioned, the Attach API is a "non-standard" API which can be changed

<br>at any time and without affecting the Java SE specification, so this

<br>JEP should rather have scope "JDK" instead. On the other hand, the

<br>fact that this functionality is not governed by the SE specification

<br>will allow different OpenJDK distributors to use a different default

<br>setting for -XX:EnableDynamicAgentLoading which has the potential to

cause a lot of confusion if we can't sattle on a common strategy.

<br>

<br>- If doing this change at all, I think it would be better to do it in

a non-LTS release first.

<br>

<br>Best regards,

<br>Volker

<br>

<br>[1] https://docs.oracle.com/en/java/javase/20/docs/api/jdk.attach/com/sun/tools/attach/VirtualMachine.html

<br>

<br>

<br>> [1]: https://mail.openjdk.org/pipermail/jigsaw-dev/2023-March/014816.html

<br>>

<br>> — Ron

<br>

<br></div></div></body></html>