On 02/06/2016 13:38, Andrew Dinn wrote:
:
Can you explain what this means in any more precise detail?
Those of us who are trying to maintain agents are currently having to
work on shifting ground where it seems the only guidance we have as to
what will and won't work is the current code. This is the second
occasion where a throwaway comment has revealed to me that plans are
afoot to change functionality that my agent (and doubtless others too)
relies on. If there are plans afoot of this nature then we need to know
about them well before it happens. OpenJDK project members -- especially
those who have implemented agents -- need to discuss whether the
resulting breakage of existing functionality is acceptable. That sort of
decision cannot be arrived at as a fait accompli simply by virtue of the
fact that your envisaged Jigsaw design will produce it as a side effect.
There has been ongoing effort to improve the security of the platform
for a long time. The ongoing effort that we have been calling
"de-privileging" involves moving non-core components out of the boot
loader and granting these components reduced permissions where possible.
This effort is not core to what we are doing here but having the JDK
structured as modules, and making it easy to map modules to class
loaders, has allowed this effort to make progress. I think most of the
discussions on specific modules has been on the core-libs-dev or
security-dev lists. There is a table in JEP 261 of the modules that have
moved and this needs to updated because we have moved several other
standard and JDK modules in recent months.
So my point is that the set of types visible via the boot loader has
been reducing steadily. This is a good thing for security but it comes
with compatibility concerns. This is very much a change for a major
release of course. One concern is custom class loaders that delegate
directly to the boot loader. Eclipse is one example - there was a brief
discussion about that on jdk9-dev some time ago. The other issue is
agents that have supporting classes on the boot class path. This code
won't be able to statically reference types in modules that have moved
to the platform class loader (platform class loader = what used to be
known as the "extension class loader"). Related is where an agent
instruments code in modules defined to the boot loader in a way that
would result in references to types in the platform class loader (the
boot loader does not delegate). I think we will need feedback and help
to assess the impact. It may be that agents working at this level aren't
depending on types in non-core modules. However, I think this thread is
a reminder that there will need to improvement documentation on this
implementation issue. So far, the document is make/common/Modules.gmk as
that is where the mapping lives.
-Alan
