Two things:

Are you planning on getting the TCK so your JVM will be trustworthy to run in prod?

Are you going to backport these changes to all the concurrent releases, or do potential consumers have to "ride HEAD" to use your JVM? Based on the number of "we're still on Java 8" comments that always show up in any JVM submission, I'd guess one would want to be mindful of the versions their audience requires otherwise it's basically your own private fork

Since I am not the target audience for this, pardon me if this seems like a silly question, but wouldn't just using a custom ClassLoader or even an Agent get this done, without having to full-on fork the JDK?

The JVM has a lot of modules and powerful features that, should perimeter defences fail, an attacker has access to. Then there's the issue of vulnerabilities in transitive dependencies upon which trusted libraries might depend, but aren't needed for deployed software, additional functionality which may be useful to an attacker. Features our software doesn't utilise may be available to a hacker to load dynamically, once perimeter defences have been breached or assist the attacker in breaching perimeter defences.

We may need to give the JVM access to keystores and private information that, should an attacker obtain them, have significant consequences. This isn't going to be the case for everyone, we have software that doesn't utilise SM authorization.

Java's existing SM infrastructure doesn't prevent loading modules or jar files based on signers, nor does it perform whitelisting of serializable classes. I've added LoadClassPermission to SecureClassLoader and SerialObjectPermission to Serialization. Java has serial filters for whitelisting, but these suffer the same problem as SecurityManager did, limited tooling to support building the whitelist. These new permissions allow policy to control loading of modules, including platform modules, based on Signer certificates etc and Serialization whitelists. The Serialization whitelist includes the code on the stack, and the authenticated user. Without the authenticated user (the source of the data), the code alone doesn't have permission to deserialize, the user, cannot deserialized with unauthorized code.

We developed high scaling policy providers (used for over a decade in production), that utilise immutability and thread confinement, we also developed a security manager with a non-blocking cache (cleaned by garbage collection), to avoid repeated permission checks from executor tasks and such like.

I've added these high-performance implementations.

However, the main feature is a principle of least privilege policy tool, with the following property -Djava.security.manager=polpAudit, The JVM will generate policy files, from least privilege principles, including execution paths with code signers, logged in users and serialized classes. This step is performed in a deployment staging environment.

When ready to deploy to production, simply set the property back to -Djava.security.manager=default and the JVM will now use high performance implementations, feel free to try it, the performance cost is unnoticeable for the majority of tasks, keep in mind the cache and hotspot will need time to warm up.

This isn't for sandboxing untrusted code; it's for constraining execution to trusted code and users and assisting in auditing. This isn't your old security manager you used for Applets, we're discarding the cruft and reusing the good.

The goal is, make it simple and practical to deploy a JVM with Authorization.

Answers to other questions:

There are no plans to backport to earlier releases, we'll follow OpenJDK's release cycle.

I have submitted a request for a TCK license.