Hello Volker,
On 2018-06-05 09:35, Volker Simonis wrote:
Hi Erik,
you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.
Correct. These are just the build changes for the build time compiler
options. Further work will be done by Hotspot engineers.
And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?
Correct, we use the old jvm variant mechanism, so this will work just
like -server/-client used to work, two completely separate libjvm.so in
separate sub directories.
/Erik
Thank you and best regards,
Volker
On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson <erik.joels...@oracle.com> wrote:
Hello,
On 2018-06-04 23:10, David Holmes wrote:
Sorry to be late to this party ...
On 5/06/2018 6:10 AM, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
Renamed the new jvm variant to "hardened".
As it is a hardened server build I'd prefer if that were somehow reflected
in the name. Though really I don't see why this should be restricted this
way ... to be honest I don't see hardened as a variant of server vs. client
vs. zero etc at all, you should be able to harden any of those.
I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
to any jvm variant, you get the flags. The name of the predefined variant
can be discussed. I initially suggested altserver because I, as you, thought
it should include server in the name. But ultimately, I don't care that much
about a name. There is also little point in defining a whole set of
predefined variants that nobody has requested. If we ever need more
specialized variants in the same image, we will add them.
So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
Yes, this is correct. The reason being that no significant performance
impact was detected, so there is no cost.
- only build hotspot "hardened" if requested; and in that case
- jvm.cfg will list -server and -hardened with server as default
Correct.
Is that right? I can see that we may choose to always build Oracle JDK
this way but it isn't clear to me that its suitable for OpenJDK. Nor why
hotspot is selectable but JDK is not. ??
We would prefer to always build with security features enabled, but the
performance impact on the JVM is so high that we want to leave it to the
user to decide, both at bulid time and at runtime. With these changes,
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
other person or entity just building the OpenJDK source will just get the
server variant for now (as has been the default for a long time), unless
they specifically ask for "hardened" or activate the new jvm feature
(--with-jvm-feature=no-speculative-cti).
We don't see the point in giving the choice on the JDK libraries simply
because there is no drawback to enabling the flags.
/Erik
Sorry.
David
-----
/Erik
On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joels...@oracle.com>
wrote:
Hello,
On 2018-06-01 14:00, Aleksey Shipilev wrote:
On 06/01/2018 10:53 PM, Erik Joelsson wrote:
This patch defines flags for disabling speculative execution for GCC
and Visual Studio and applies
them to all binaries except libjvm when available in the compiler. It
defines a new jvm feature
no-speculative-cti, which is used to control whether to use the flags
for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with
this new feature added.
I think the classic name for such product configuration is "hardened",
no?
I don't know. I'm open to suggestions on naming.
"hardened" sounds good to me.
The change looks good as well.
/Jesper
/Erik
-Aleksey
