[External] : Re: New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Brice Dutheil]

> > For white-box testing of code in user modules, build tools and testing
frameworks should automatically emit --add-exports, --add-opens, and
--patch-module for the module under test, as appropriate (for example,
patching the module under test with the contents of the test module allows
the testing of package access methods)… APM tools should require the
application to deploy their agents with the -javaagent or -agentlib option.
This explicitly grants the agent permission to instrument and modify
classes. Mocking libraries that employ an agent to change classes' behavior
should do the same.

> I.e. mocking libraries should load their agent at startup and have no
need to load it dynamically.

Exactly! I'm not advocating against this change, but clearly given the
popularity of mocking libraries (and likely other related test libraries)
this will surely make this change highly visible once enabled.

> > 2. I was wondering however about the relation of this JEP with the
following property :
> >
> > ```
> > -Djdk.attach.allowAttachSelf=true
> > ```
> >
> > This affects the attachment not agent loading, however I believe this
JEP should at least mention this property as well as it seems directly tied
to one of the mentioned problems about detecting who loads the agent.
>
>
> The JEP already does. It says:
>
> > To maintain integrity, JDK 9 and later releases prevent code from
connecting to the current JVM by default.
>
> Perhaps I’ll mention the property by name.

Indeed thank you, I missed that.



Apologies if I missed that in the previous exchanges. Auditability was
mentioned, but if functionality has to be restored agent loading will be
enabled via `-XX:+EnableDynamicAgentLoading`, but then the code base could
load any agent. It might still be possible to audit via `
-Djdk.instrument.traceUsage` but you're still exposed if some functionality
is needed. Is it considered to restrain dynamic agent loading to specific
libraries, e.g. via an _allow-list_, like the `--add-opens` options or the
only option forward to restrain is declaring them via `--javaagent` /
`--agentlib`.

-- Brice


On Wed, May 17, 2023 at 1:21 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 15 May 2023, at 23:24, Brice Dutheil <brice.dutheil at gmail.com> wrote:
> >
> > Hi,
> >
> > I do share some concerns of the community, however many have voiced it
> with a better english that I could ever do. But I'd like to mention two
> things:
> >
> > 1. There is another usage that I think will be visibly impacted : in
> tests it's often necessary to alter part of the system to stress some
> parts. In doing so some libraries offer these capabilities, often by
> relying on an ad hoc agent ; I hope this falls in the useful application of
> this mechanism. I understand the goal is mostly about applications running
> in production, yet it's likely the effect will be visible well before code
> reaches production.
>
> The informational JEP linked at the beginning of this one (
> https://openjdk.org/jeps/8305968) refers to this use-case when it comes
> to both agents and other encapsulation-breaking mechanisms:
>
> > For white-box testing of code in user modules, build tools and testing
> frameworks should automatically emit --add-exports, --add-opens, and
> --patch-module for the module under test, as appropriate (for example,
> patching the module under test with the contents of the test module allows
> the testing of package access methods)… APM tools should require the
> application to deploy their agents with the -javaagent or -agentlib option.
> This explicitly grants the agent permission to instrument and modify
> classes. Mocking libraries that employ an agent to change classes' behavior
> should do the same.
>
> I.e. mocking libraries should load their agent at startup and have no need
> to load it dynamically.
>
> >
> > 2. I was wondering however about the relation of this JEP with the
> following property :
> >
> > ```
> > -Djdk.attach.allowAttachSelf=true
> > ```
> >
> > This affects the attachment not agent loading, however I believe this
> JEP should at least mention this property as well as it seems directly tied
> to one of the mentioned problems about detecting who loads the agent.
>
>
> The JEP already does. It says:
>
> > To maintain integrity, JDK 9 and later releases prevent code from
> connecting to the current JVM by default.
>
> Perhaps I’ll mention the property by name.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230517/5efb6424/attachment.htm>