Usage of Virtual Threads and ScopedValue

[Peter Firmstone]

Hello OpenJDK folk,

Just thought I'd mention our use of Virtual Threads and replacing the 
usage of ThreadLocal with ScopedValue.

I've been hacking a fork of OpenJDK on github, 
pfirmstone/jdk-with-authorization: JDK main-line development 
<https://github.com/pfirmstone/jdk-with-authorization>

It uses a heavily modified Authorization implementation to lock down the 
vm and replace vintage SM implementation code that has either been 
removed or is scheduled for future removal, it also supports permission 
checks on virtual threads.   The implementation focuses on scalability 
with immutability with non blocking weak caches.   AccessControlContext 
uses a factory cache to minimise the number of immutable 
AccessControlContext instances, for example, many virtual threads will 
share context. The cache implementation is injected to avoid 
dependencies during jvm bootstrap.

Virtual threads are used in the SM implementation to execute permission 
checks in parallel, and avoid blocking native threads, such as 
SocketPermission etc.

jdk-with-authorization/src/java.base/share/classes/au/zeus/jdk/authorization/sm/CombinerSecurityManager.java 
at trunk · pfirmstone/jdk-with-authorization 
<https://github.com/pfirmstone/jdk-with-authorization/blob/trunk/src/java.base/share/classes/au/zeus/jdk/authorization/sm/CombinerSecurityManager.java>

Basically ScopedValue is used to detect and limit recursion, which can 
occur when a permission check requires other permission checks to 
complete.   The implementation is relatively basic, but it works well, 
eg, for more info see the link above.

@Override
     public void checkPermission(Permission perm) throws SecurityException {
         Integer call = TRUSTED_RECURSIVE_CALL.isBound() ? 
TRUSTED_RECURSIVE_CALL.get() : null;
         if (call != null && call > 7) {
             /* This is a recursive permission check, there's a 
permission on
              * the stack that requires privilege to determine whether 
it is implied.
              * We can't continue indefinitely, as it will cause a stack 
overflow,
              * however we can allow a limited number of nested 
permission checks,
              * the same permission check may be repeated numerous 
times, in recursion.
              */
             throw new AccessControlException("Too many recursive 
permission checks", perm);
         }
         Object context = getSecurityContext();
         checkPermission(perm, context);
     }

For the curious, the trusted platform has been reduced to only the 
java.base module, furthermore modifications have been made to limit 
trust of certain classes within the trusted platform domain, to allow 
JAAS Subject policy based authorization to take priority.

There's a tool to generate policy files at deployment, only the 
permissions needed to perform required functionality and execution paths 
are generated.   Additional execution paths that are not exercised that 
require privileges will not have permission to execute.

Static permissions, such as URLPermission granted by URLClassLoader have 
been removed, to prevent URL injection attacks and allow policy to 
determine allowed URL's.

There are additional permission's such as LoadClassPermission, 
NativeAccessPermission, SerialObjectPermission and additional 
ManagementPermission checks in native code.

No effort will be made to sandbox untrusted code, instead the focus is 
on preventing the VM from executing untrusted code by requiring 
authentication and authorization.

StackWalker with ScopedValue was tested to replace the native stack 
walk, however this lead to difficulties in early loading of java class 
dependencies and memory stability issues.   The native stack walk itself 
is a relatively small section of code and has been retained, as have 
permission check hooks.

AccessControlContext's implementation has been simplified and made 
immutable for virtual thread support.

Permission implementations are no longer Serializable, some minor 
breaking changes have been made that OpenJDK dev's wouldn't have been 
permitted to make.  Needless to say the implementation is modern and 
easier to maintain.

My reason for hacking OpenJDK:

pfirmstone/JGDMS: Infrastructure for providing secured micro services, 
that are dynamically discoverable and searchable over ipv6 networks 
<https://github.com/pfirmstone/JGDMS>

-- 
Regards,
  
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20250820/d8a9d695/attachment.htm>