> On 18 May 2023, at 21:45, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: > > Hi Ron, > > And in that JEP there is... > > "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”. > > It is these types of statements in that JEP that are adding to my confusion. > What is being restricted? Where and how is that restriction being enforced > given that it can apparently be turned on?
By “restricted” we mean “disallowed by default unless the application allows it.” We try to use that terminology consistently. In this JEP we’re just “preparing to restrict”, which means that unless explicitly allowed by the flag, there will only be a warning. > And the big question once again, how will this impact observability? Our assessment, detailed in the JEP is that the impact will be low because most observability mechanisms either don’t require agents at all (JMX, JFR, logging) or can work with agents loaded at startup (APM), and in the less common cases when dynamically loaded agents are needed (ad hoc deep troubleshooting), adding a command-line flag should not be onerous. One special case we single out in the JEP is the use of JVM TI based profilers that may be deployed in production. However, because JFR is able to perform profiling much more efficiently (i.e. with less overhead) than anything we could ever hope to expose via JVM TI (because it can obtain stack traces at a high frequency in a special and very efficient way that coordinates with the JIT and the code cache) the long term direction is to offer the capabilities offered by such profilers, such as native method profiling, in JFR. We hope that the warning in this JEP will give us another opportunity to further assess the impact on valid tool use and see if our evaluation (both the one done back in 2017 when we first announced this change and again recently) is too optimistic. Since no new information between 2017 and now has come to light, I don’t think anything short of a warning at runtime would help us learn more than we already know. > > As for dynamic attach, it’s not like everyone can just decide to dynamically > attach an agent to a running JVM. There is a wee bit of security in play. It > feel like turning on dynamic attach equates to consent and that equates to > better integrity is a false equivalency. That is absolutely correct and is covered in the JEP: > … attaching a tool is triggered by a human operator with appropriate > operating-system credentials. This human in the loop grants approval to alter > the application, so serviceability tools are not subject to the integrity > constraints imposed upon other code…. Unfortunately, we have not found a > simple and automatic way to distinguish between a serviceability tool that > dynamically loads an agent and a library that dynamically loads an agent. > Giving free reign to tools would imply giving free reign to libraries, which > is tantamount to giving up on integrity by default. The JEP mentions that we’ve explored some ways that could allow us to distinguish between tools and libraries in the future. For example, we could grant trusted certificates to tools that would be verified by the JVM (and invalidating certificates that end in the hands of libraries) or have a CAPTCHA-like challenge-response mechanism that ensures there’s a human in the loop that gives consent. Unfortunately, both of these are quite complex, although we may end up doing them in the future. When we do, or if we come up with a simpler way to distinguish between a tool and a library, authenticated tools may not need to flag to load an agent. BTW, one idea that was explored some years ago (this change was already decided back in 2017 and announced in JEP 261) was to try and distinguish between tools and libraries by examining the OS’s process hierarchy. Unfortunately, that technique turned out not to be robust. — Ron
