Re: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities

[Bernd Eckenfels]

Is that actually safe to allow low priveledged user context to attach and 
control to a higher prived? It can at least overwrite files, but probably also 
inject code? On the native level a ptrace(2) would probably not be allowed.

Gruß
Bernd
— 
https://bernd.eckenfels.net

Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature

[Bernd]

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls  wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to 
> use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

src/java.management/share/classes/javax/management/loading/MLet.java line 68:

> 66: import javax.management.ReflectionException;
> 67: 
> 68: import static com.sun.jmx.defaults.JmxProperties.MLET_LIB_DIR;

Do those 2 statics in JmxProperties also need to be removed?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441216307

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

[Bernd]

On Tue, 28 Nov 2023 14:36:19 GMT, Alan Bateman  wrote:

>> btw for the following (system/native/runtime/embryotic) Reader thread tseems 
>> to be no java method marked "native" on the stack, what case is that?
>> 
>> 
>> "JDWP Event Helper Thread" #22 daemon prio=10 os_prio=0 cpu=0.00ms 
>> elapsed=65.02s tid=0x01fc4f7e9970 nid=0x32e0 runnable  
>> [0x]
>>java.lang.Thread.State: RUNNABLE
>> 
>> "JDWP Command Reader" #23 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=65.02s 
>> tid=0x01fc4f7ea480 nid=0x69c4 runnable  [0x]
>>java.lang.Thread.State: RUNNABLE
>> 
>> "Notification Thread" #24 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=64.99s 
>> tid=0x01fc4f7f12a0 nid=0x75f0 runnable  [0x]
>>java.lang.Thread.State: RUNNABLE
>> 
>> jshell> mx.getThreadInfo(23)
>> $17 ==> "JDWP Command Reader" daemon prio=10 Id=23 RUNNABLE (in native)
>> 
>> funfact: its not in the list:
>> 
>> 
>> jshell> mx.getAllThreadIds()
>> $11 ==> long[8] { 1, 2, 3, 4, 5, 24, 25, 26 }
>
>> btw for the following (system/native/runtime/embryotic) Reader thread tseems 
>> to be no java method marked "native" on the stack, what case is that?
>> 
>> ```
>> "JDWP Event Helper Thread" #22 daemon prio=10 os_prio=0 cpu=0.00ms 
>> elapsed=65.02s tid=0x01fc4f7e9970 nid=0x32e0 runnable  
>> [0x]
>>java.lang.Thread.State: RUNNABLE
>> 
>> "JDWP Command Reader" #23 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=65.02s 
>> tid=0x01fc4f7ea480 nid=0x69c4 runnable  [0x]
>>java.lang.Thread.State: RUNNABLE
> 
> I think you are asking about JVMTI RunAgentThread. That's what the debugger 
> agent uses to create its own threads. RunAgentThread is specified to hide the 
> thread from Java APIs, it's nothing to do with this PR.

Well.. it has to do in so far, that those threads are not hidden - the 
ThreadInfo sees it and says "isNative". But ok if this is not expected, then 
indeed it does not need to be documented.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1408093987

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

[Bernd]

On Tue, 28 Nov 2023 06:15:54 GMT, Alan Bateman  wrote:

>> Note that there is no answer for the "syscall" case mentioned as it depends 
>> on the code that makes the syscall: if from a native method then yes; if 
>> from the VM then no.
>
>> Note that there is no answer for the "syscall" case mentioned as it depends 
>> on the code that makes the syscall: if from a native method then yes; if 
>> from the VM then no.
> 
> Right, if the thread invokes a Java native method then it may or may not 
> invoke a system call, it doesn't matter, the ThreadInfo::isInNative method is 
> just reporting a bit of thread state to say that it is in a native method. 
> Same thing when calling a native function with the FFM API, the native 
> function may be a syscall,  or the native code may invoke a syscall, it 
> doesn't matter to ThreadInfo::isInNative as it just returns a bit of thread 
> state.

btw for the following (system/native/runtime/embryotic) Reader thread tseems to 
be no java method marked "native" on the stack, what case is that?


"JDWP Event Helper Thread" #22 daemon prio=10 os_prio=0 cpu=0.00ms 
elapsed=65.02s tid=0x01fc4f7e9970 nid=0x32e0 runnable  [0x]
   java.lang.Thread.State: RUNNABLE

"JDWP Command Reader" #23 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=65.02s 
tid=0x01fc4f7ea480 nid=0x69c4 runnable  [0x]
   java.lang.Thread.State: RUNNABLE

"Notification Thread" #24 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=64.99s 
tid=0x01fc4f7f12a0 nid=0x75f0 runnable  [0x]
   java.lang.Thread.State: RUNNABLE

jshell> mx.getThreadInfo(23)
$17 ==> "JDWP Command Reader" daemon prio=10 Id=23 RUNNABLE (in native)

funfact: its not in the list:


jshell> mx.getAllThreadIds()
$11 ==> long[8] { 1, 2, 3, 4, 5, 24, 25, 26 }

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1407852578

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

[Bernd]

On Sat, 25 Nov 2023 07:32:20 GMT, Jaikiran Pai  wrote:

>> Alan Bateman has updated the pull request with a new target base due to a 
>> merge or a rebase. The incremental webrev excludes the unrelated changes 
>> brought in by the merge/rebase. The pull request contains five additional 
>> commits since the last revision:
>> 
>>  - Change link to downcallHandle
>>  - Merge
>>  - Simplify wording
>>  - Merge
>>  - Initial commit
>
> src/java.management/share/classes/java/lang/management/ThreadInfo.java line 
> 552:
> 
>> 550:  * java.lang.invoke.MethodHandle method handle} obtained from the
>> 551:  * {@linkplain java.lang.foreign.Linker native linker}.
>> 552:  *
> 
> This area is new to me, but I happened to be in this code few days back. I'm 
> mostly curious on what the actual definition of a thread being in native 
> means.
> When a thread is executing any of the following,  does it end up being 
> considered as being in a "native method":
> 
> - A syscall (for example, `write()`)
> - A C function exposed by a platform specific library
> - A JNI method (either part of the JDK or the application) which then may or 
> may not do any syscall or C function call on a platform specific library

I would agree, it should state if runtime functions (including those doing a 
syscall) will be counted here. (For JNi i would not need it to be spelled out, 
on the other hand it would help, since it makes clear we don’t mean c2 code)

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1406716462

Re: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

[Bernd]

  
  
  

	
	If you keep instrumentation (and i don’t think you want to remove it), don’t make it harder to use programmatically… that really does not make much sense. And please don’t add captcha-like mechanism that’s ridiculous. Backport the fix to turn it off, I will be the first to actually use it. But everything else…GrussBernd-- http://bernd.eckenfels.net

  

 Von: serviceability-dev  im Auftrag von Ron Pressler Gesendet: Montag, Mai 1, 2023 12:24 AMAn: Mike Hearn Cc: Dan Heidinga ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default 





Hi Mike!


On 30 Apr 2023, at 19:59, Mike Hearn  wrote:



we’ve begun to explore means other than the flag to allow a tool to load an agent at runtime


How about restricting access to the jcmd socket. For in-VM code it can
be blocked at the filesystem implementation level, and for
sub-processes by using the operating system APIs to determine if the
other side of the socket is part of the same process tree at connect
time. This would avoid the need for new UI to re-enable existing jcmd
functionality, whilst preventing code loaded into the VM from
connecting back to that same VM. Only truly external tools could
trigger agent loading, or modules that had been given permission to do
that.






Determining the process on the other side and/or maintaining the integrity of the process tree is not easy on all OSes.



That is assuming native code is restricted of course but that's a
whole other kettle of fish. I don't quite understand how the plan is
meant to work when it reaches that stage. JNI is so widely used and so
many libraries would break that you'd either just immediately see
workarounds appear, like build systems concatenating lists of flags
from META-INF files, or it'd just cause a lot of chaos and upgrade
rejection. It'd also have to be dynamically controllable for plugins,
so then you'd also get people running their apps inside classloaders
that auto-grant any request to load native code.





No libraries will break and no workarounds would be possible once all loopholes are closed. All you’d need to do is grant the module permission to load/use native libraries, be it through JNI or FFM.


Build tools may do whatever they want, but it’s important to remember that the low-integrity free-for-all worked more-or-less only while Java was relatively stagnant. Once the platform started evolving more rapidly we saw many applications break in the
 Java 8 -> 9 upgrade due to deep dependencies that relied on JDK internals in the days before strong encapsulation. 




There must be a better way?





Before thinking about other ways, I think it’s best to first acknowledge the problem, and that is that we wish for two fundamentally contradictory things: On the one hand, we want it to be easy to break other people’s code’s encapsulation when we need
 to, and on the other we want features that fundamentally depend on encapsulation not being broken, such as smooth upgrades, robust security mechanisms, and future Leyden features. Both may be good, but they are in conflict. Because we can't to have our invariants
 and break them too, someone must choose between one and the other.


But I also don’t think it’s a very complicated choice. The view of the Java ecosystem as a hotbed of encapsulation-breaking is gradually becoming outdated. Much of the necessity to break encapsulation came about due to the platform’s stagnation in the
 JDK 6-8 timeframe. While the ability to break encapsulation is being restricted, the problems that required it in the first place are also being addressed. The number of uses that require breaking strong encapsulation is shrinking.




Maybe the problem can be recast as one of build-time observability?
One concept I experimented with for my own build system is the notion
of "control reports", a generalization of lockfiles. The build
generates text files describing things you care about, and these are
then checked in to vcs. There is a build mode that doesn't write the
generated reports on disk, instead it verifies there's no difference
and exits if there are. By checking the reports into version control
and using OWNERS files + code reviews various policies can be
enforced.

In this context it'd work like so: the JVM would be changed to look
for a flags file in the JAR containing the main class/main module as
part of its startup. JVM flags can thus be shipped as part of the app,
formalizing an already existing convention that's today implemented
with shell scripts. Build systems can generate this flag file from
their existing lists of JVM flags, and/or compute it automatically by
merging flag files found in any library JARs. For people who don't
care about deprivileging libs (prototyping, learners, people who only
use in-house code etc) this will keep things working as it does today.





A main JAR, when used, is alrea

Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

[Bernd]

  
  
  

	
	Hello,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.GrussBernd-- http://bernd.eckenfels.net

  

 Von: serviceability-dev  im Auftrag von Volker Simonis Gesendet: Freitag, April 28, 2023 5:39 PMAn: Ron Pressler Cc: jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: JEP draft: Disallow the Dynamic Loading of Agents by Default On Wed, Apr 19, 2023 at 12:29 AM Ron Pressler  wrote:
>
> Hi.
>
> Following last month’s email about changing the default of
> EnableDynamicAgentLoading [1], we’ve now published two JEP drafts.
>
> The first is an informational JEP describing what integrity is and why we need it,
> and motivates what changes are required to get it (which include the
> restriction of dynamically loaded agents among others):
>
> https://openjdk.org/jeps/8305968 Integrity and Strong Encapsulation
>

>- Use sun.misc.Unsafe to access and modify private fields.
>
>- Load a native library that employs JNI to call private methods and
>  set private fields. (The JNI API is not subject to access checks.)
>
>- Load an agent that changes code in a running application,
>  using an API intended for tools only.
>
>   To attain our goal of integrity by default, we will gradually restrict
>   these APIs and close all loopholes in a series of upcoming JEPs, ensuring
>   that no library can assume superpowers without the application's consent.
>   Libraries that rely on these APIs should spend the time remaining until
>   they are restricted to prepare their users for any necessary changes.

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

Do you really plan to make JNI an optional feature which will have to
be manually enabled at startup? What will be the benefit? 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? And what would be the benefit of disabling it by default
for the user except increased "integrity"? I.e. do you have some
concrete examples of planned features X, Y, Z which will only work
with disabled JNI? Will these features be Java SE features or
implementation specific OpenJDK-only features?

> The second touches on the specifics of dynamically loaded agents and the
> proposed change:
>
> https://openjdk.org/jeps/8306275 Disallow the Dynamic Loading of Agents by Default
>

>Agents are used by profiling tools to instrument Java applications,
>but agents can also be misused to undermine the integrity of the
>Java Platform.

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.

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

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.

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

Re: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4]

[Bernd]

On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs  wrote:

>> Define an internal jdk.internal.util.Architecture enumeration and static 
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, 
>> PPC64LE`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The values of the system property `os.arch` is unchanged.
>> 
>> The API is similar to the jdk.internal.util.OperatingSystem enum created by 
>> #[12931](https://git.openjdk.org/jdk/pull/12931).
>> Uses in `java.base` and a few others are included but other modules will be 
>> done in separate PRs.
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Correct spelling of isAARCH64 in WIndows AttachProviderImpl

src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:

> 46: // might be running in a 32-bit VM on a 64-bit platform.
> 47: // addressSize will be correctly 32
> 48: if (Architecture.isX64() && ADDRESS_SIZE == 64) {

Is there a difference to Architecture.is64bit (I.e. is the later or the former 
runtime vs compiletime

src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:

> 75:  */
> 76: @ForceInline
> 77: public static boolean isARM() {

It should define what’s the difference to aarch64 for example will aarch64 also 
be arm, but arm32 wont? (Or remove)

test/jdk/jdk/internal/util/ArchTest.java line 58:

> 56: @Test
> 57: public void nameVsCurrent() {
> 58: String osArch = 
> System.getProperty("os.arch").toLowerCase(Locale.ROOT);

Is it planned to determine os.arch with the same enum in the future (keeping 
the legacy names)?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158982643
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158988981
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158993835

Re: RFR: 8257967: JFR: Events for loaded agents [v12]

[Bernd]

On Thu, 30 Mar 2023 18:59:30 GMT, Markus Grönlund  wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>>  Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most 
>> agents are started and initialized on the command line, but agents can also 
>> be loaded dynamically during runtime. Because command line agents initialize 
>> during the VM startup sequence, they add to the overall startup time latency 
>> in getting the VM ready. The events will report on the time the agent took 
>> to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the 
>> APIs in the package 
>> [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS 
>> stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and 
>> events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over 
>> running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file 
>> containing the instrumentation code. The options will be the specific 
>> options passed to the .jar file as part of launching the agent, for example, 
>> on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line 
>> (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, 
>> and "initializationTime" is the duration of executing the initialization 
>> method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; 
>> hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM 
>> Tools Interface 
>> (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). 
>> This kind of agent, sometimes called a native agent, is a platform-specific 
>> binary, sometimes referred to as a library, but here it means a .so or .dll 
>> file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent 
>> and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = 
>> "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but 
>> here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an 
>> agent-specified callback routine. The "initialization" is when the JVM sent 
>> or would have sent the JVMTI VMInit event to a specified callback. 
>> "initializationTime" is the duration to execute that specific callback. If 
>> no callback is specified for the JVMTI VMInit event, the 
>> "initializationTime" will be 0.
>> 
>>  Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as 
>> these are built on top of the JDK native library, "instrument", using a 
>> many-to-one mapping. At the level of the JVM, the only representation of 
>> agents after startup is through JvmtiEnv's, which agents request from the 
>> JVM during startup and initialization — as such, mapping which JvmtiEnv 
>> belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" 
>> interacts with the JVM, we can build this mapping to track what JvmtiEnv's 
>> "belong" to what JavaAgent. This mapping now lets us report the 
>> Java-relevant context (name, options) and measure the time it takes for the 
>> JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code 
>> used to represent agents, AgentLibrary. The previous implementation was 
>> located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, 
>> prims/agent.hpp and prims/agentList.hpp. Breaking out thi

Re: [External] : Re: Disallowing the dynamic loading of agents by default

[Bernd]

  
  
  

	
	Gregg I don’t understand your problem, nearly all desktop java programs I know (and there are not many left) come with included runtimes. The user just does not care about Java versions. Also i dont really know any enterprise desktops which ship (only) recent plan java runtimes. Your problem with java feels very constructed or local to your organisations deficiencies. And I bet if you are not allowed to install a different runtime, you are not allowed to install a Java application without IT approval/support either. Not to mention that you certainly will not be able or allowed to dynamically Instrument them - that’s simply not a usecase for the change at hand (especially not since it’s just a config option).GreetingsBernd-- http://berndeckenfels.net

  

 Von: serviceability-dev  im Auftrag von Gregg Wonderly Gesendet: Dienstag, März 28, 2023 5:36 PMAn: Andrew Dinn Cc: Ron Pressler ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: [External] : Re: Disallowing the dynamic loading of agents by default 

> On Mar 28, 2023, at 4:13 AM, Andrew Dinn  wrote:
> 
> Greeg,
> 
> I won't respond point by point to your comments as I cannot see any great value in doing so. I really only want to make one general comment about your account below, which is that you appear to me to be relaying your own experience as a desktop Java user and universalising it to all users and uses of Java. While I acknowledge that you are correct to state that there can be problems with maintaining a consistent desktop setup for Java I'll counter that with two important qualifying arguments which undercut your account.

Again, the supposition is that somehow users of software systems are always surrounded by version planning and management.  This is just not the case. People use software for its functionality not because the platform has certain features.  The platform is what enables software systems to be constructed and used.  When the platform changes it’s feature set or design and removes features or disables the default use of those features, that lack of backward compatibility, when unmanaged by the platform, creates havoc for users and software developers who are providing software systems in vertical markets or into communities of users who are not educated or knowledgable enough to understand what any of these words actually refer to. 

> Firstly, the problems that you describe are general ones that apply when it comes to software configuration management for a highly user-specific and often, in consequence, highly variable environment like a desktop. They are not problems that are specific to Java or other language runtimes Even within that category many runtimes, especially language runtimes, suffer from problems with installed version mismatches and in many cases these have been notably far worse problems than Java (as for example the Python 2/3 fiasco mentioned by Andrew Haley). However, that is not to say that the problem lies with the runtime itself.

Your supposition is again that somehow everyone has the benefit of having a guru or appointed party that manages all of their software and versioning needs.  I used the example of corporate users to draw on that environments “random” upgrade timelines.  Users get new machines as something fails or get new versions of software based on “bugs” or “risks” or other drivers that are completely unrelated to software development timelines of third party suppliers of software systems.

Suggesting that just because this has happened historically, that somehow it provides the relief to do it as well is the point I am trying to counter with my arguments here.

> Version management problems cannot simply be resolved by preserving Java (or any other deployed software) in aspic. At least some minimal level of upgrade of a runtime like Java is needed to deal with emerging security and critical functional problems. However, in the longer term any platform will also need to incorporate larger scale modifications in order to cater for the continuous, dramatic change that we have seen and continue to see in all hardware and operating systems. Java has not stood still over the last 25 years for very good reasons.

Removing features and changing how the platform handles features such that software deployment or software systems have to change is the problem.  There are so many things that have been changed to no real advantage to developers.  Java 9 changes for “modularity” were really only targeted changes to try and manage people plugging into private APIs, because the public APIs were not providing needed features and it was difficult or impossible to use the platform without those changes.  This speaks to the ineffective nature of the platform management overall.  Historically, and I assert this over and over, because I was in the room where it happened, Sun was only interested in selling servers.  Oracle is again only interested in selling serve

Re: Disallowing the dynamic loading of agents by default

[Bernd]

  
  
  

	
	Gregg i have to disagree, not only is Java one of the most stable platform out there but also the „Enterprise Desktop“ couldn’t care less about the default of this switch. GrussBernd -- http://bernd.eckenfels.net

  

 Von: serviceability-dev  im Auftrag von Gregg Wonderly Gesendet: Freitag, März 24, 2023 11:42 PMAn: Andrew Dinn Cc: Ron Pressler ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: Disallowing the dynamic loading of agents by default Lot’s of people use Java in places where there is no “release” cycle of Java version in control of the users.  These are “corporate users” in most cases and they have Java applications that they are using which will just “stop working” when a new version of Java is installed.

Over the years, I’ve watch any favoritism towards java on the desktop or as a general solution programing language wane, because it’s undependable as a platform.  You never no when something will break as these “stability” changes occur.  People who use software systems are in large part not programers or language/platform experts.  The in ability of Oracle and many others to understand how detrimental this behavior has been is just mind blowing.

People like myself end up looking like whining babies because we come back every once in a while to see if there is something useful happening in Java development that might finally stabilize the platform on the desktop and other business environments and low and behold write-once-run-anywhere is found to still be unimplemented and basically non appreciated. It’s just a sad, sad thing to see happening.

Sun first did this with Java 1.2.  The Community beat up on Sun severely and everything quieted down for a while.  Then we had the JDK 1.5 release where my much mentioned volatile reachability optimizations broke software all over the place.

This is not happening in any other language I am aware of.  The people at Sun who were causing all the problems seemed to have gone on to Oracle and there is just a core group of people who just do not understand how horrible Java looks these days because of how much basic functionality got completely broken when a new version of Java showed up on general purpose computing and working software just stopped working…

Gregg Wonderly

> On Mar 24, 2023, at 12:21 PM, Andrew Dinn  wrote:
> 
> Hi Ron,
> 
> Thank you for providing a heads up on the proposed JEP. The Red Hat Java team have been discussing this proposal. We have reviewed the original discussion and also the surrounding debate which established requirements for adaptation of Jigsaw to incorporate the needs of agents.
> 
> As an aside, I'll note that a thorough review was necessary /even/ in my case, despite the fact that I was an active party, because the discussion occurred, and corresponding decisions were made, quite some time ago. I mention this because it may explain the air of surprise and the desire to reiterate some of the original debate on the part of some respondents in this thread, who perhaps were not party, or only tangentially party, to the discussion.
> 
> That also suggests that there may be a lot users who are not aware that the -XX:+EnableDynamicAgentLoading switch exists or do not really understand why it exists i.e. that there is a broad education issue at play here.
> 
> We do have some concerns about the JEP, specifically about the timing of its delivery. These are probably best addressed via the normal review process. In particular that will ensure the discussion happens in a more suitable and more widely subscribed forum than the Jigsaw list. However, I will briefly mention our concerns in this reply. Before that let me start with a few disclaimers:
> 
> - We acknowledge that there is little to be gained from re-iterating arguments made in the previous discussion (although that does not imply the JEP review would not benefit from new arguments, especially from those who were not involved in that discussion)
> 
>  - We recognize that the purpose of the -XX:+EnableDynamicAgentLoading switch is to offer a platform integrity guarantee and that this change of the default reflects a desire to prioritise integrity over the flexibility that agents provide
> 
>  - We recognize that the proposal is only proposing to flip a configuration default rather than detract from (or modify) available functionality
> 
>  - We recognize that changing this default will still allow (*most*) users to configure the behaviour they desire
> 
>  - We recognize that this advance notice has been given precisely to ensure that anyone wishing to deploy on jdk21 an app that relies on use of agents has time to plan appropriate configuration for their deployment
> 
>  - We recognize that this change of default is not being proposed for backport and hence that it will largely only affect the relatively small number of users who are currently developing for jdk21+
> 
> So, given that as a base for our comments where 

Re: [External] : Re: Disallowing the dynamic loading of agents by default

[Bernd]

  
  
  

	
	Hello,I don’t have a strong feeling towards or against changing the default. While I agree that having ad-hoc access to diagnostics is good, I am also ok with having to prepare that once, even when it means I can’t catch the first instability.Having said that I had a lot of bad experiences with APM tools instrumentations my application without the application owner beeing aware of it (causing a lot of support effort). From that point of view I will probably disable the dynamic loading by default, since most of my tools used in production don’t require ad-hoc instrumentation (mostly only Thread.print or Heapdump). So thanks for the reminder that this option exists (and thanks for fixing it to apply to all loading).GrussBernd-- http://bernd.eckenfels.net

  

 Von: serviceability-dev  im Auftrag von Jaroslav Bachorik Gesendet: Montag, März 20, 2023 11:37 AMAn: Ron Pressler Cc: Andrei Pangin ; jigsaw-...@openjdk.org ; serviceability-dev@openjdk.org Betreff: Re: [External] : Re: Disallowing the dynamic loading of agents by default Hi,On Mon, Mar 20, 2023 at 11:11 AM Ron Pressler  wrote:




Hi.


The majority of serviceability tools don’t require dynamically loading an agent, and the majority of applications never load an agent dynamically.The majority of the JDK built-in tools, I would say. What about eg. the JMC agent? 


True, there are some tools that will be affected, which is why the decision was to introduce the flag in JDK 9 and to announce this change, but change the default in a later version to give tools ample time to prepare their users. The rationale
 for this change then hasn’t changed, but will be reiterated in a JEP (we just wanted to announce this ahead of the JEP to give tool authors another reminder more than six months ahead of JDK 21). The only change between then and now is that even fewer use
 cases require dynamically loaded agents, and so the impact is even smallerAs a maintainer of one of such tools I can confidently say that this change will either kill the tool as the ease of use will be gone or the workaround (eg. using JAVA_TOOL_OPTIONS) will completely defeat the purpose of this change. Having to put a flag when starting the JVM to allow dynamic loading of agents sounds a bit nonsensical to me - it would be much easier to directly add the agent to the JVM startup and then implement a lightweight control protocol over socket/shared memory to enabled/disable the agent features dynamically. 


It is also true that, when starting an application you don’t know that you *will* need to load an agent, but in most situations you know that you might. E.g. processes that are too critical to bring down even for deep maintenance (although not
 many of these are written in modern version of Java anyone) or canary services that are under trial. The relatively few sophisticated users who know how to write ad-hoc agents can even opt to enable dynamic agent loading on all their servers; these users are
 better equipped to can weigh the risks and tradeoffs involved.Wouldn't having this enabled system-wide actually defeat the purpose of having this flag? Considering that the dynamic attach can be performed only on the same host under the same user as the target process there seems to be a very small chance of loading agents accidentally. In the end people would set up their systems to enabled dynamic agent loading via eg. JAVA_TOOL_OPTIONS and we will be in the same place as before, with the additional hurdle of setting everything up.


Finally, some tools that require a dynamically loaded JVM TI agents, such as profilers that profile native code, are so tied to the VM's internals that the best place for them is in the JDK. If anything, the bigger problem is not that profilers
 are used too much in production, but too little, including less advanced ones that don’t require an agent. There is plenty of time to enhance the JDK’s built-in profiling capabilities ahead of demand.I think this is an overly optimistic view. It is *much more* difficult to enhance the JDK's built-in profiling capabilities than do the same in an external profiling agent.Overall, I don't seem to understand the anticipated attack vectors this change is supposed to prevent. AFAIK, in order to do the dynamic agent load one needs to have full access to the target process. That means that there are more convenient and straightforward ways to do anything nefarious than loading a JVMTI agent. Am I missing some other usages where the JVMTI agent would actually give access to something which would be otherwise inaccessible considering that the attacher and attachee must be on the same host and under the same user?Cheers,-JB- 


— Ron


On 20 Mar 2023, at 01:21, Andrei Pangin  wrote:


Hi all,

Serviceability has been one of the biggest Java strengths, but the proposed change is going to have a large negative impact on it.

Disallowing dynamic agents by defa