Re: question on exports to

[Jochen Theodorou]

On 03.06.2016 22:20, Alex Buckley wrote:
[...]

Why don't you believe it? The "Under The Hood" presentation shows that
layer creation makes the JVM aware of modules and their relationships.


because I was thinking it will lower performance. Sure, benchmarks are 
often driven by code of callsites, that are actually no moving much, and 
in such benchmarks there will be no problem. And yes, this checkc has to 
be done only once, unless the callsite has to be reevaluated... Still it 
will increase the one time cost, unless you meet one of those callsites, 
that require the JVM to regularly deopt. But on the other hand the JVM 
is not good at recovering from a deopt anyway (at least that is my 
perception)... so maybe it does not really matter in the end.



Later, when the JVM resolves the descriptor of an invokevirtual
instruction, it checks that the current class (containing invokevirtual)
can access the class referenced in the descriptor, and this check takes
module membership, exports, and readability into account. Can the
current class's module read the target class's module, and does the
target class's module export the target class to (at least) the current
class's module?


I see.. and I assume that counts for get/setField and all invoke 
instructions including invokeSpecial and newinstance.



There's a clear contrast between the two-way check performed by the JVM,
and the one-way check (exports only, readability "for free") performed
by Core Reflection.


so... odes reflection code still produce runtime helper classes for 
invocation? That is then a dynamic module based solution?


bye Jochen

Re: question on exports to

[Alex Buckley]

On 6/3/2016 11:49 AM, Jochen Theodorou wrote:

On 01.06.2016 20:54, Peter Levart wrote:
[...]

Modules are part of language. Their exports / requires form a logical
layer of additional access checks to what we had before
(public/protected/package/private qualifiers on classes / members), but
are treated the same way during runtime. Together they form language
accessibility rules. There are exceptions, notably in reflection:
- Member.setAccessible(true) can not be used to circumvent lack of
exports
- readability is implicitly provided for reflective access in general


so if I load a class that tries to use a class from a different module
and this class is not exported, the call will fail?


Yes.


I am talking here about invokevirtual and the others. Sure, that is
not supposed to compile, but java is not the only things that
generates bytecode. I somehow fail to believe that for each
invocation of a method the module system is checked...


Why don't you believe it? The "Under The Hood" presentation shows that 
layer creation makes the JVM aware of modules and their relationships. 
Later, when the JVM resolves the descriptor of an invokevirtual 
instruction, it checks that the current class (containing invokevirtual) 
can access the class referenced in the descriptor, and this check takes 
module membership, exports, and readability into account. Can the 
current class's module read the target class's module, and does the 
target class's module export the target class to (at least) the current 
class's module?


There's a clear contrast between the two-way check performed by the JVM, 
and the one-way check (exports only, readability "for free") performed 
by Core Reflection.


Alex


or that such a class will fail verification...
which I also find difficult to believe. Your second point actually
suggests that there is some kind of post compilation check. Could you
please confirm if there is or not?


So the trick with Lookup shown above can be used to invoke a private or
package-private method via TheInvoker.invoke() like it was invoked
directly:

class MyOtherClass {
  private void myPrivateMethod() {
 ...
 }

 void someMethod() {
 TheInvoker.invoke(MethodHandles.lookup(), this,
"myPrivateMethod");
 }
}

...as well as other public methods in modules that export packages to
the Lookup owner (the module of the class that obtains the Lookup object
via MethodHandles.lookup()).


that is actually good for our invokedynamic part.

bye Jochen

Re: question on exports to

[Jochen Theodorou]

On 01.06.2016 21:07, Alex Buckley wrote:

Pretend
you never heard of Module::addReads, it's for a use case that doesn't
matter here (generation of bytecode with constant pool references to
classes in other modules).


good advice, that I will follow ;)


Core Reflection is still bound by the Java language's notion of
accessibility, so calling newInstance() on a Class or get() on a Field
or invoke() on a Method will perform an access check in SE 9 just like
in SE 8. The access check has two parts, as previously discussed, but by
policy the first part (X-reads-Y) is a "yes" for these reflective
operations ... that leaves second part where the underlying
class/field/method must be exported to the code calling
newInstance()/get()/invoke(). That's why setAccessible has been
@CallerSensitive since the module system implementation was merged into
JDK 9.


which is much less of a problem for us

bye Jochen

Re: question on exports to

[Jochen Theodorou]

On 01.06.2016 20:54, Peter Levart wrote:
[...]

Modules are part of language. Their exports / requires form a logical
layer of additional access checks to what we had before
(public/protected/package/private qualifiers on classes / members), but
are treated the same way during runtime. Together they form language
accessibility rules. There are exceptions, notably in reflection:
- Member.setAccessible(true) can not be used to circumvent lack of exports
- readability is implicitly provided for reflective access in general


so if I load a class that tries to use a class from a different module 
and this class is not exported, the call will fail? I am talking here 
about invokevirtual and the others. Sure, that is not supposed to 
compile, but java is not the only things that generates bytecode. I 
somehow fail to believe that for each invocation of a method the module 
system is checked...  or that such a class will fail verification... 
which I also find difficult to believe. Your second point actually 
suggests that there is some kind of post compilation check. Could you 
please confirm if there is or not?



So the trick with Lookup shown above can be used to invoke a private or
package-private method via TheInvoker.invoke() like it was invoked directly:

class MyOtherClass {
  private void myPrivateMethod() {
 ...
 }

 void someMethod() {
 TheInvoker.invoke(MethodHandles.lookup(), this, "myPrivateMethod");
 }
}

...as well as other public methods in modules that export packages to
the Lookup owner (the module of the class that obtains the Lookup object
via MethodHandles.lookup()).


that is actually good for our invokedynamic part.

bye Jochen

Re: White-listing sensitive linker targets

[Mike Samuel]

On Thu, Jun 2, 2016 at 3:37 PM, Alex Buckley  wrote:
> On 6/2/2016 10:22 AM, Mike Samuel wrote:
>>
>> It sounds like the tech lead, specialists, and build master can
>> exercise oversight using tools that just
>>
>> 1. look at the exports...to... relationships which should be apparent
>> from module declarations in bytecode per
>> http://openjdk.java.net/projects/jigsaw/spec/sotms/#qualified-exports
>
>
> Yes, the qualified exports should drive everything, since they're
> bulletproof. (A module can choose to augment its own exports at run time,
> but hopefully the overseers recognize that more as a "feature" for Sally to
> use judiciously than as a "bug" which weakens the authority of the static
> white-list.)

I agree re "judicious."

One of my goals is to encourage architectures that allow auditors to
prioritize so that,
for a particular security property, most of the code requires only
cursory review.

It's difficult to keep tight bounds on a secure kernel when review is happening
concurrently with development unless you can compute that kernel statically and
see that it is more or less stable.



>> 2. check that sensitive packages are only contained in modules defined
>> in build artifacts signed by the right group.
>
>
> Yes, this is a job for the build system. The placement of packages in
> modules is something that the module system has to take on trust.

Understood.


>> What about JSR 223 style script engines?
>> Can an embedder of an interpreter or bytecode compiler create a module
>> that includes the scripting engine and just the stuff that the scripts
>> need and be sure that, whether the script engine uses reflection under
>> the hood, or compiles to bytecode?  Or does all that stuff tend to end
>> up in the unnamed module?
>
>
> The way that frameworks use the module system is a deep topic, but
> ultimately a JSR-223 ScriptEngineFactory is just a service provider, so you
> can create a module which 'provides' a class implementing
> ScriptEngineFactory and which 'requires' java.scripting + the other modules
> it needs. The module can't access anything which isn't exported to it,
> regardless of whether the access is from bytecode or via Core Reflection or
> via the Language Model or via MethodHandle lookup.

Great.   So this can serve as a defense-in-depth with but not a replacement for
interpreter sandboxing.
The base module contains java.io so modularity can't, by itself,
prevent a crafted script
from using ObjectInputStream to forge objects by deserializing crafted
byte strings,
but the script would need to have access to the class of the object
it's trying to forge via
the module system.

Re: Non-core components are no longer defined to the boot loader

[Alan Bateman]

(I've changed the subject line as this thread is no longer about multi 
release JARs).


On 03/06/2016 11:13, Andrew Dinn wrote:


:
Of course, no one is against security just as no one is against apple
pie. Unfortunately, "de-privileging" is one of those vanilla words like
"modernisation" that can hide more than it reveals.
There is no intention to hide anything. In general then APIs such as 
CORBA, JAX-WS, JDBC, and other non-core APIs have no business being 
defined to the boot loader with all permissions.



:
The visibility of said types may well appear to Jigsaw devs to have been
reducing steadily in what is (or, if you take into account the EA
program, /was/ until very recently) unreleased and untried code.
However, this is still going to amount to a step change in the operation
of the JDK runtime for anyone moving from JDK8 to JDK9. hat step change
may not affect many applications directly but it certainly looks like it
is going to affect the continuity of operation of the tools and
middleware that a lot of those applications rely on. That's not simply
an implementation and/or documentation issue; it goes to the heart of
what functionality developers can rely on from their tools and middleware.

I don't think these issues have really begun to be addressed yet. I hate
to say this at such a late stage in the game (no one /wants/ to be a
Cassandra) but I think it is critical that the consequences of this
"de-privileging" are investigated and discussed properly before JDK9 is
released. That's not just wrt an obvious special case like agent code,
it definitely also includes the requirements of middleware code.
The "de-privileging" has been going on for a long time. The CORBA and EE 
components were moved to the extension class loader in early 2015 for 
example. All this has been happening in the JDK 9 main line where there 
are weekly early access builds and continuous "out reach" - mostly 
communication and interaction with projects to encourage continuous 
testing with the JDK 9 builds.


As regards specs then the draft APIs for Java SE 9 specify that all Java 
SE types be visible via the platform class loader. This is the first 
time that this will be specified.





There is a big list of issues on the Jigsaw issues list still to be
talked through yet the current JDK9 implementation is moving
relentlessly towards a looming release deadline. How do the current
release timescales marry with the need for investigation and discussion?
How and when are the results of any such discussion going to be taken
into account and applied to the JDK? Is the plan to release what we have
now and then try to back-patch fixes? That sounds to me like it would be
a very bad move for JDK9 and, indeed, Java as a whole. What's the
alternative plan?
I think you mean the JSR 376 issues list. I'm sure Mark will be moving 
this along soon. Once there are conclusion on issues that require spec 
or implementation changes then we'll bring those changes to JDK 9.


-Alan

hg: jigsaw/jake/hotspot: 2 new changesets

[alan . bateman]

Changeset: 9d90a83ddcc0
Author:lana
Date:  2016-06-02 20:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9d90a83ddcc0

Added tag jdk-9+121 for changeset 7e293105dbb0

! .hgtags

Changeset: 2593cd67408d
Author:alanb
Date:  2016-06-03 07:00 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2593cd67408d

Merge

! .hgtags

hg: jigsaw/jake/langtools: 19 new changesets

[alan . bateman]

Changeset: 5b344cfeb8c8
Author:sadayapalam
Date:  2016-05-25 19:30 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5b344cfeb8c8

8047024: 7 ANNOT tests in JCK9 test suite fail with an AssertionError for 
exception_index
Summary: Fix incorrect assertion about exception index already being set.
Reviewed-by: mcimadamore

! 
src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
+ test/tools/javac/annotations/typeAnnotations/8047024/T8047024.java
+ test/tools/javac/annotations/typeAnnotations/8047024/T8047024_01.java

Changeset: 1ef94fda9c07
Author:vromero
Date:  2016-05-25 11:33 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1ef94fda9c07

8152360: deprecate javah
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javah/JavahTask.java
! src/jdk.compiler/share/classes/com/sun/tools/javah/resources/l10n.properties
+ test/tools/javac/T8152360/DeprecateJavahTest.java
! test/tools/javah/T6893943.java
! test/tools/javah/VersionTest.java

Changeset: 487e6d33c635
Author:darcy
Date:  2016-05-25 22:32 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/487e6d33c635

8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations
Reviewed-by: jjg

! 
src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java

Changeset: da5d8d3e445f
Author:sadayapalam
Date:  2016-05-26 18:22 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/da5d8d3e445f

8154052: Java compiler error displays line from the wrong file
Summary: Compiler should update the diagnostic source properly.
Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/diags/EagerInitCheck.java
+ test/tools/javac/diags/EagerInitCheck.out
+ test/tools/javac/diags/IEagerInitCheck.java

Changeset: 10eaadcaba97
Author:rfield
Date:  2016-05-26 07:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/10eaadcaba97

8157917: JShell: shutdown could cause remote JDWP errors to be visible to users
8157918: JShell tests: StartOptionTest displays insufficient information to 
diagnose failures
Reviewed-by: vromero

! src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIConnection.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIExecutionControl.java
! test/jdk/jshell/StartOptionTest.java

Changeset: 4344c9ad3c9d
Author:mcimadamore
Date:  2016-05-26 18:09 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4344c9ad3c9d

8157895: langtools launcher.sh-template script is broken
Summary: Add logic to quote Xpatch paths
Reviewed-by: jjg

! make/build.xml
! make/intellij/runConfigurations/javac.xml
! make/intellij/runConfigurations/javadoc.xml
! make/intellij/runConfigurations/javah.xml
! make/intellij/runConfigurations/javap.xml
! make/intellij/runConfigurations/jshell.xml
! make/intellij/runConfigurations/sjavac.xml
! make/launcher.sh-template

Changeset: 961cba2189e5
Author:lana
Date:  2016-05-26 17:18 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/961cba2189e5

Merge


Changeset: 894bff248e4f
Author:jjg
Date:  2016-05-26 10:45 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/894bff248e4f

8156962: javac should support options specified in _JAVAC_OPTIONS
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java
+ test/tools/javac/modules/EnvVarTest.java

Changeset: 39d44146e8d9
Author:jjg
Date:  2016-05-26 10:46 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/39d44146e8d9

Merge


Changeset: 6d69114ec506
Author:rfield
Date:  2016-05-26 12:38 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6d69114ec506

8157953: JShell tests: reenable ToolBasicTest
8080883: JShell tool: tool does not report errors if -startup and -nostartup 
flags are specified
Reviewed-by: vromero

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! 
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! test/jdk/jshell/StartOptionTest.java
! test/jdk/jshell/ToolBasicTest.java

Changeset: a50a635008a3
Author:jjg
Date:  2016-05-26 17:35 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a50a635008a3

8157608: deprecate old entry points for javadoc tool
Reviewed-by: ksrini

! 
src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Main.java
+ src/jdk.javadoc/share/classes/com/sun/tools/javadoc/package-info.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java

Changeset: 5e4854abed51
Author:rfield
Date:  

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 26df083b5aa3
Author:lana
Date:  2016-06-02 20:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/26df083b5aa3

Added tag jdk-9+121 for changeset 9a5fc5a27560

! .hgtags

Changeset: 339c2df3a451
Author:alanb
Date:  2016-06-03 07:01 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/339c2df3a451

Merge

hg: jigsaw/jake/nashorn: 6 new changesets

[alan . bateman]

Changeset: 93c5020dd976
Author:sundar
Date:  2016-05-25 11:03 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/93c5020dd976

8157789: Nashorn sample/test.js should not use undocumented System property
Reviewed-by: mchung

! samples/test.js

Changeset: 9c62b456f075
Author:sundar
Date:  2016-05-25 15:14 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9c62b456f075

8157680: Callback parameter of any JS builtin implementation should accept any 
Callable
Reviewed-by: hannesw, mhaupt

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeWeakMap.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeWeakSet.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java
+ test/script/basic/JDK-8157680.js
+ test/script/basic/JDK-8157680.js.EXPECTED

Changeset: 59d31c4e3f77
Author:sundar
Date:  2016-05-25 19:25 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/59d31c4e3f77

8157819: TypeError when a java.util.Comparator object is invoked as a function
Reviewed-by: mhaupt, forax, hannesw

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
+ test/script/basic/JDK-8157819.js

Changeset: 5992041b0794
Author:lana
Date:  2016-05-26 17:19 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5992041b0794

Merge


Changeset: e9e0f65bc003
Author:lana
Date:  2016-06-02 20:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e9e0f65bc003

Added tag jdk-9+121 for changeset 5992041b0794

! .hgtags

Changeset: 5953226daa06
Author:alanb
Date:  2016-06-03 07:01 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5953226daa06

Merge

! .hgtags
! samples/test.js

hg: jigsaw/jake/jaxp: 2 new changesets

[alan . bateman]

Changeset: 06a850e64ad5
Author:lana
Date:  2016-06-02 20:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/06a850e64ad5

Added tag jdk-9+121 for changeset a265b8116058

! .hgtags

Changeset: d838b6e10f5e
Author:alanb
Date:  2016-06-03 07:00 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d838b6e10f5e

Merge

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: d3b178691715
Author:lana
Date:  2016-06-02 20:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/d3b178691715

Added tag jdk-9+121 for changeset fb771fa3a986

! .hgtags

Changeset: 0dc9705d3746
Author:alanb
Date:  2016-06-03 07:01 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/0dc9705d3746

Merge