<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">Hi Alex,</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">I am using OpenJDK 17 and I am enabling the Azure Application Insights agent programmatically (see [1]).</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="ContentPasted0">[1]: <a href="https://github.com/brunoborges/aks-jvm-benchmark/blob/main/src/main/java/examples/azure/aks/springboot/Application.java#L14" id="LPlnk194389">https://github.com/brunoborges/aks-jvm-benchmark/blob/main/src/main/java/examples/azure/aks/springboot/Application.java#L14</a></span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">The reason I like this approach is because I can manage the Java Agent as a regular Maven Dependency, and get alerts on updates
(or, knock-on-wood, security updates).</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">As far as I recall 'jdk.attach.allowAttachSelf=true' is the case in JDK 11 and 17.</span></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Alex Buckley <alex.buckley@oracle.com><br>
<b>Sent:</b> May 12, 2023 12:18 PM<br>
<b>To:</b> Bruno Borges <Bruno.Borges@microsoft.com><br>
<b>Cc:</b> jdk-dev@openjdk.org <jdk-dev@openjdk.org><br>
<b>Subject:</b> [EXTERNAL] Re: New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Bruno,<br>
<br>
Am I right to assume that these cases involve applications running on <br>
Java 8? If they were on 9+, the developers would already have had to run <br>
with `-Djdk.attach.allowAttachSelf=true` to let the app load the agent <br>
into the local JVM.<br>
<br>
I sense that you're describing an 8 environment for two reasons:<br>
<br>
1. Because command line options were relatively rare in that <br>
environment, and mostly concerned JVM tuning when they did appear. But <br>
in the 9+ environment, it's relatively common to use command line <br>
options (esp. --add-opens) because some library four levels down in the <br>
app demands to use private methods in java.lang.<br>
<br>
2. Because you rightly look "forward" to jlink to see if it can smooth <br>
the 8->11 / 8->17 / 8->21 migration, by having the image automatically <br>
enable agents without any app developer learning new flags.<br>
<br>
Apologies if I've misinterpreted your use cases, but I really want to <br>
understand the reticence around more-command-line-options.<br>
<br>
Alex<br>
<br>
On 5/11/2023 2:55 PM, Bruno Borges wrote:<br>
> Ron,<br>
> <br>
> In the cases I've seen, it is the application that is loading the agent <br>
> programmatically, first thing they do in their static_void_main method.<br>
> <br>
> This has some benefits like allowing the application to depend on an <br>
> agent as they do with any other library, through a dependency management <br>
> tool (Maven/Gradle), and having more easily version upgrading mechanisms.<br>
> <br>
> The -javaagent deployment model is not an option to this, nor is the <br>
> flag to enable the programmatically approach, as it requires the <br>
> application *developer* to tune JVM flags to do so.<br>
> <br>
> Only possible solution I thought about was to give jlink a flag that <br>
> would enable the feature. I wonder if this has been considered.<br>
> <br>
> Sent from mobile device.<br>
> ------------------------------------------------------------------------<br>
> *From:* jdk-dev <jdk-dev-retn@openjdk.org> on behalf of Ron Pressler <br>
> <ron.pressler@oracle.com><br>
> *Sent:* Thursday, May 11, 2023 11:37:56 AM<br>
> *To:* Jack Shirazi <jacks@fasterj.com><br>
> *Cc:* jdk-dev@openjdk.org <jdk-dev@openjdk.org><br>
> *Subject:* [EXTERNAL] Re: New candidate JEP: 451: Prepare to Disallow <br>
> the Dynamic Loading of Agents<br>
> The general policy in effect since JEP 261 [1] was delivered in JDK 17 <br>
> (and included the dynamic agents change) is that the application and not <br>
> libraries gets to decide what encapsulation-bypassing mechanisms are <br>
> allowed. In the case of agents, JEP 451 states:<br>
> <br>
>> To ensure that the owner of an application approved the use of agents, JDK 5 required agents to be specified on the command line with the -javaagent or -agentlib options, and loaded the agents immediately at startup. This represented an explicit grant of
privileges by the application owner.<br>
> <br>
> This is in line with the policy; letting libraries decide that they want <br>
> to deploy an encapsulation-bypassing agent without the applications <br>
> explicit consent is not. The full motivation behind the policy, and what <br>
> integrity (not to be confused with security) means, is explained in this <br>
> information JEP draft: <br>
> <a href="https://openjdk.org/jeps/8305968">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F8305968&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dl6HMB2ZxOYl0IdqYnu4z6y2XxkqOHqjhk8x0RMrLmY%3D&reserved=0</a>
<<a href="https://openjdk.org/jeps/8305968">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F8305968&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dl6HMB2ZxOYl0IdqYnu4z6y2XxkqOHqjhk8x0RMrLmY%3D&reserved=0</a>><br>
> <br>
> [1]: <br>
> <a href="https://openjdk.org/jeps/261">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F261&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xvgG7uF1ZSipWX40YWy02QYbqFERbKUmKoX8PsAAov8%3D&reserved=0</a>
<<a href="https://openjdk.org/jeps/261">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F261&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xvgG7uF1ZSipWX40YWy02QYbqFERbKUmKoX8PsAAov8%3D&reserved=0</a>><br>
> <br>
>> On 11 May 2023, at 11:11, Jack Shirazi <jacks@fasterj.com> wrote:<br>
>> <br>
>> This proposes to deprecate one mechanism for agent loading, but the ability to run an agent in the JVM is unchanged. This means that if disallowed in future, there will still be absolutely no change in "the balance between serviceability, which involves
ad-hoc changes to running code, and integrity, which assumes that running <br>
> code is not arbitrarily changed". Applying the deprecation will still <br>
> leave the exact same ability for arbitrary changes to the code.<br>
>> <br>
>> For libraries that may use this mechanism, I checked the <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvekey.cgi%3Fkeyword%3Djava&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F0zQIn%2Fj31tHLHW%2Fq21mFZD%2B50M4XM1f09%2FLULDh3uA%3D&reserved=0</a>
<<a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvekey.cgi%3Fkeyword%3Djava&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F0zQIn%2Fj31tHLHW%2Fq21mFZD%2B50M4XM1f09%2FLULDh3uA%3D&reserved=0</a>>
CVEs for the last five years and can't find any recorded abuse of it. I find it hard to believe that developers wouldn't know that their dependencies use this, if they do.<br>
>> <br>
>> Ultimately, integrity may be preferred, but there is a balance. For example we are not proposing to remove java agent capability, reflection, dynamic class loading, etc, all of which in one way or another violate integrity, because these are features which
make the JVM hugely successful.<br>
>> <br>
>> I don't see the benefit here. What future improvement would happen if the deprecation is subsequently applied?<br>
>> <br>
>> On 08/05/2023 20:17, Mark Reinhold wrote:<br>
>>> <a href="https://openjdk.org/jeps/451">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F451&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=siIqnZZuErDTRDNfRVNOpnduYZaUH0SZHqEggAfL6Xw%3D&reserved=0</a>
<<a href="https://openjdk.org/jeps/451">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F451&data=05%7C01%7CBruno.Borges%40microsoft.com%7Cd79bf66c4208403fb1d208db531da43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638195159016723982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=siIqnZZuErDTRDNfRVNOpnduYZaUH0SZHqEggAfL6Xw%3D&reserved=0</a>><br>
>>> <br>
>>> Summary: Issue warnings when agents are loaded dynamically into a<br>
>>> running JVM. These warnings aim to prepare users for a future release<br>
>>> which disallows the dynamic loading of agents by default in order to<br>
>>> improve integrity by default. Serviceability tools that load agents at<br>
>>> startup will not cause warnings to be issued in any release.<br>
>>> <br>
>>> - Mark<br>
> <br>
</div>
</span></font></div>
</body>
</html>