May 2024 - leyden-dev

Questions about the Hermetic Java project
by Magnus Ihse Bursie 09 Jun '25

09 Jun '25

First some background for build-dev: I have spent some time looking at the build implications of the Hermetic Java effort, which is part of Project Leyden. A high-level overview is available here: https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Hermetic Java faces several challenges, but the part that is relevant for the build system is the ability to create static libraries. We've had this functionality (in three different ways...) for some time, but it is rather badly implemented. As a result of my investigations, I have a bunch of questions. :-) I have gotten some answers in private discussion, but for the sake of transparency I will repeat them here, to foster an open dialogue. 1. Am I correct in understanding that the ultimate goal of this exercise is to be able to have jmods which include static libraries (*.a) of the native code which the module uses, and that the user can then run a special jlink command to have this linked into a single executable binary (which also bundles the *.class files and any additional resources needed)? 2. If so, is the idea to create special kinds of static jmods, like java.base-static.jmod, that contains *.a files instead of lib*.so files? Or is the idea that the normal jmod should contain both? 3. Linking .o and .a files into an executable is a formidable task. Is the intention to have jlink call a system-provided ld, or to bundle ld with jlink, or to reimplement this functionality in Java? 4. Is the intention is to allow users to create their own jmods with static libraries, and have these linked in as well? This seems to be the case. If that is so, then there will always be the risk for name collisions, and we can only minimize the risk by making sure any global names are as unique as possible. 5. The original implementation of static builds in the JDK, created for the Mobile project, used a configure flag, --enable-static-builds, to change the entire behavior of the build system to only produce *.a files instead of lib*.so. In contrast, the current system is using a special target instead. In my eyes, this is a much worse solution. Apart from the conceptual principle (if the build should generate static or dynamic libraries is definitely a property of what a "configuration" means), this makes it much harder to implement efficiently, since we cannot make changes in NativeCompilation.gmk, where they are needed. That was not as much a question as a statement. 🙂 But here is the question: Do you think it would be reasonable to restore the old behavior but with the new methods, so that we don't use special targets, but instead tells configure to generate static libraries? I'm thinking we should have a flag like "--with-library-type=" that can have values "dynamic" (which is default), "static" or "both". I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files into a single jmod file (see question 2 above), then it definitely is. In general, the cost of producing two kinds of libraries are quite small, compared to the cost of compiling the source code to object files. Finally, I have looked at how to manipulate symbol visibility. There seems many ways forward, so I feel confident that we can find a good solution. One way forward is to use objcopy to manipulate symbol status (global/local). There is an option --localize-symbol in objcopy, that has been available in objcopy since at least 2.15, which was released 2004, so it should be safe to use. But ideally we should avoid using objcopy and do this as part of the linking process. This should be possible to do, given that we make changes in NativeCompilation.gmk -- see question 5 above. As a fallback, it is also possible to rename symbols, either piecewise or wholesale, using objcopy. There are many ways to do this, using --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this takes a file with a list of symbols). Thus we can always introduce a "post factum namespace" by renaming symbols. So in the end, I think it will be fully possible to produce .a files that only has global symbols for the functions that are part of the API exposed by that library, and have all other symbols local, and make this is in a way that is consistent with the rest of the build system. Finally, a note on Hotspot. Due to debugging reasons, we export basically all symbols in hotspot as global. This is not reasonable to do for a static build. The effect of not exporting those symbols will be that SA will not function to 100%. On the other hand, I have no idea if SA works at all with a static build. Have you tested this? Is this part of the plan to support, or will it be officially dropped for Hermetic Java? /Magnus

7 38

Statistics about CDS effectiveness
by Stephane Nicoll 11 Jun '24

11 Jun '24

Hey, I hope this mailing list is the right place for this. I am working with Sébastien Deleuze on the Spring team and we've been focusing quite a bit on CDS lately and how it can be easily leveraged by our user base. One thing we quickly found out was that the cache can be more or less effective depending on the way you start the app (classloaders, non deterministic list of jar files, etc). Initially, we were testing the startup time and comparing when CDS wasn't enabled. I think there must be a better way and, for the lack of finding one, I've developed a (very) pragmatic approach of parsing the JVM logs and producing a report[1]. The tool has improved a bit for our own use case, creating the cache and providing a report of the warnings that were issued (to spot packages that couldn't be managed and why). Parsing the logs is good enough for our little testing there but we were wondering if there was an appetite (or need) to productize this. We were thinking that JFR events could be an option. Thanks, S. [1] https://github.com/snicoll/cds-log-parser -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

2 2

git: openjdk/leyden: premain: 8333222: Allow SerialGC and ParallelGC to be used in Leyden training run
by duke 31 May '24

31 May '24

Changeset: c67940c7 Author: iklam <ilam3388(a)gmail.com> Date: 2024-05-30 22:55:47 +0000 URL: https://git.openjdk.org/leyden/commit/c67940c709d4dfb0d5295f73971d33d40eeea… 8333222: Allow SerialGC and ParallelGC to be used in Leyden training run ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/metaspaceShared.cpp + test/hotspot/jtreg/runtime/cds/appcds/leyden/LeydenGCFlags.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java ! test/lib/jdk/test/lib/cds/CDSAppTester.java

1 0

git: openjdk/leyden: premain: 2 new changesets
by duke 31 May '24

31 May '24

Changeset: f7d6f17a Author: iklam <ilam3388(a)gmail.com> Date: 2024-05-30 20:18:34 +0000 URL: https://git.openjdk.org/leyden/commit/f7d6f17abd2228dd53dc2dc64ce4fd8fdb89d… Removed Leyden-specific workaround in test cases ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesAsCollectorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesCastFailureTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesInvokersTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesPermuteArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java Changeset: 7e9d14f0 Author: Ioi Lam <iklam(a)openjdk.org> Committer: iklam <ilam3388(a)gmail.com> Date: 2024-05-30 21:21:24 +0000 URL: https://git.openjdk.org/leyden/commit/7e9d14f002b5f46bd8680e792e80d71e21d0f… 8332340: Add JavacBench as a test case for CDS Reviewed-by: ccheung, matsaave ! test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBenchApp.java ! test/lib/jdk/test/lib/StringArrayUtils.java ! test/lib/jdk/test/lib/cds/CDSAppTester.java

1 0

Hermetic Java project meeting
by Magnus Ihse Bursie 30 May '24

30 May '24

This is my summary of what was said in today's meeting: * Jiangli reported that her team had done extensive testing and not seen any problems, both with just the static launcher as generated by the leyden branch, and with bundled user applications using the One Jar (?) tool. They tested JDK tier 1, and an suite of Google's internal tests. When testing JTReg tests with native libraries, these were dynamically loaded. * Alan asked about Hotspot JTReg tests that launched "java". Jiangli reported that they had not seen any problems, but my understanding was that there was some confusion if any such tests were actually run. I think this is something that will need further attention, but if someone said they would look into it, I missed it. * Jiangli will get numbers on how much time is added to the GHA testing if we add building and linking of static libraries, without fixing so we can compile to a single set of object files. * We did not fully come to a conclusion if compiling on a single set of object files for static and dynamic linking was a hard requirement or not, but at a minimum it is a desirable goal. (My personal opinion is that is a hard requirement if the GHA build times are seriously affected otherwise.) There are basically two problems prohibiting single object file compilation: 1) using dynamic checks instead of #ifdefs for code that differs between static and dynamic. 2) Handling the difference between JNI_OnLoad (as required for dynamic libraries) and JNI_OnLoad_<libname> (as required for static libraries). * The leyden branch has basically solved both these problems. The first one could more or less be integrated already (given perhaps some discussion on exactly *how* the JDK should discover in runtime if it is static or dynamic), but the latter requires a spec change to be integrated. * I think everyone agreed that moving on with a spec change was a good idea, regardless of if this is blocker or not, but I don't recall that there were any concrete next steps decided. Ron and Alan said that we do spec changes all the time so it will not add as much bureaucracy as one might fear. * Regarding which native libraries to include, I think we agreed on the following: - Static linking will only support headless-only builds (in which the build system excludes the AWT library that does "headful" stuff -- otherwise there would be duplicate symbols) - As a first delivery, the build system will just create a static version of the "java" launcher (not jar, javac, etc). This will include all native libraries from all modules that are included in the build. - Going forward, the correct solution is to make jlink create a launcher that includes just the native libraries from the modules that is included in the jlink command. This will require jlink to understand how to call the native linker. - Somewhere in there we probably also needs to have jlink know about headless-only vs normal (headless or "headful" determined on runtime), so it can create a java.desktop output that includes only the headless library. * Magnus reported that the refactoring and fixing of technical debt that was required for doing static builds properly has just been finished, and that his attention is now turning into creating a properly integrated system for generating static builds alongside dynamic builds. * Jiangli and Magnus will work outside the meeting to resolve the build issues Magnus faced with the hermetic java branch in the Leyden repo. * Just before the meeting unfortunately had to be aborted, Jiangli mentioned that they had discovered issues with some JDK native libraries when using objcopy to localize all non-visible symbols. It was at the time of writing not clear what those issues were. Jiangli will report back with what they found. (And while I had not time to mention it on the meeting, I will also look into this.) /Magnus

2 14

git: openjdk/leyden: premain: Added checks for G1GC during new workflow training run
by duke 29 May '24

29 May '24

Changeset: 4faa7202 Author: iklam <ilam3388(a)gmail.com> Date: 2024-05-29 10:22:19 +0000 URL: https://git.openjdk.org/leyden/commit/4faa72029abb86b55cb33b00acf9f3a18ade4… Added checks for G1GC during new workflow training run ! README.md ! src/hotspot/share/cds/metaspaceShared.cpp

1 0

Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
by David Holmes 25 May '24

25 May '24

On 17/05/2024 9:43 pm, Aman Sharma wrote: > Hi Chen, > > > java.lang.invoke.LambdaForm$MH/0x00000200cc000400 > > I do see this as output when I pass -verbose:class. However, based on my > experiments, I have seen that neither an agent passed via 'javaagent' > nor an agent passed via 'agentpath' is able to intercept this hidden class. How did you try to intercept them? Hidden classes are not "loaded" in the normal sense so won't trigger class load events. > Also, I was a bit confused since I saw somewhere that the names of > hidden classes are null. But thanks for clarifying here. The JEP clearly defines the name format for hidden classes - though the final component is VM specific (and typically a hashcode). https://openjdk.org/jeps/371 Cheers, David ----- > > avoid dynamic class loading > > I don't see dynamic class loading as a problem. I only mind some > unstable generation aspects of them which make it hard to verify them > based on an allowlist. > > For example, if this hidden class is generated with the exact same name > and the exact same bytecode during runtime as well, it would be easy to > verify it. However, I do see the names are based on some sort of memory > address so and I don't know what bytecode it has so I don't have > suggestions to make them stable as of now. For Proxy classes, I feel it > can be addressed unless you disagree or some involved in Project Leyden > does. :) Thank you for forwarding my mail there. > > Regards, > Aman Sharma > > PhD Student > KTH Royal Institute of Technology > https://algomaster99.github.io/ <https://algomaster99.github.io/> > > ------------------------------------------------------------------------ > *From:* liangchenblue(a)gmail.com <liangchenblue(a)gmail.com> > *Sent:* Friday, May 17, 2024 1:23:58 pm > *To:* Aman Sharma <amansha(a)kth.se> > *Cc:* core-libs-dev(a)openjdk.org <core-libs-dev(a)openjdk.org>; > leyden-dev(a)openjdk.org <leyden-dev(a)openjdk.org> > *Subject:* Re: Deterministic naming of subclasses of > `java/lang/reflect/Proxy` > > Hi Aman, > For `-verbose:class`, it's a JVM argument instead of a program argument; > so when you run a java program like `java Main`, you should call it as > `java -verbose:class Main`. > When done correctly, you should see hidden class outputs like: > [0.032s][info][class,load] > java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: > __JVM_LookupDefineClass__ > The loading of java.lang.invoke hidden classes requires your program to > use MethodHandle features, like a lambda. > > I think the problem you are exploring, that to avoid dynamic class > loading and effectively turn Java Platform closed for security, is also > being accomplished by project Leyden (as I've shared initially); Thus, I > am forwarding this to leyden-dev instead, so you can see what approach > Leyden uses to accomplish the same goal as yours. > > Regards, Chen Liang > > On Fri, May 17, 2024 at 4:40 AM Aman Sharma <amansha(a)kth.se > <mailto:amansha@kth.se>> wrote: > > __ > > Hi Roger, > > > Do you have ideas on how to intercept them? My javaagent is not able > to nor a JVMTI agent passed using `agentpath` option. It also does > not seem to show up in logs when I pass `-verbose:class`. > > > Also, what do you think of renaming the proxy classes as suggested > below? > > > Regards, > Aman Sharma > > PhD Student > KTH Royal Institute of Technology > School of Electrical Engineering and Computer Science (EECS) > Department of Theoretical Computer Science (TCS) > <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ > <https://algomaster99.github.io/> > ------------------------------------------------------------------------ > *From:* core-libs-dev <core-libs-dev-retn(a)openjdk.org > <mailto:core-libs-dev-retn@openjdk.org>> on behalf of Roger Riggs > <roger.riggs(a)oracle.com <mailto:roger.riggs@oracle.com>> > *Sent:* Friday, May 17, 2024 4:57:46 AM > *To:* core-libs-dev(a)openjdk.org <mailto:core-libs-dev@openjdk.org> > *Subject:* Re: Deterministic naming of subclasses of > `java/lang/reflect/Proxy` > Hi Aman, > > You may also run into hidden classes (JEP 371: Hidden Classes) that > allow classes to be defined, at runtime, without names. > It has been proposed to use them for generated proxies but that > hasn't been implemented yet. > There are benefits to having nameless classes, because they can't be > referenced by name, only as a capability, they can be better > encapsulated. > > fyi, Roger Riggs > > > On 5/16/24 8:11 AM, Aman Sharma wrote: >> >> Hi, >> >> >> Thanks for your response, Liang! >> >> >> > I think you meant CVE-2021-42392 instead of 2022. >> >> >> Sorry of the error. I indeed meant CVE-2021-42392 >> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>. >> >> >> > Leyden mainly avoids this unstable generation by performing a >> training run to collect classes loaded >> >> >> Would love to know the details of Project Leyden and how they >> worked so far to focus on this goal. In our case, the training run >> is the test suite. >> >> >> > GeneratedConstructorAccessor is already retired by JEP 416 [2] >> in Java 18 >> >> >> I did see them not appearing in my allowlist when I ran my study >> subject (Apache PDFBox) with Java 21. Thanks for letting me know >> about this JEP. I see they are re-implemented with method handles. >> >> >> > How are you checking the classes? >> >> >> To detect runtime generated code, we have javaagent that is hooked >> statically to the test suite execution. It gives us all classes >> that that is loaded post the JVM and the javaagent are loaded. So >> we only check the classes loaded for the purpose of running the >> application. This is also why we did not choose -agentlib as it >> would give classes for the setting up JVM and javaagent and we the >> user of our tool must the classes they load. >> >> >> Next, we have a `ClassFileTransformer` hook in the agent where we >> produce the checksum using the bytecode. And we compare the >> checksum with the one existing in the allowlist. The checksum >> computation algorithm is same for both steps. Let me describe how >> I compute the checksum. >> >> >> 1. I get the CONSTANT_Class_info >> <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo". >> 2. Since, the name of the class is used to refer to its types >> members (fields/method), I get all CONSTANT_Fieldref_info >> <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo". >> 3. Next, since the naming of the fields, in Proxy classes, are >> also suffixed by numbers, for example, `private static Method >> m4`, we rewrite the UTF8 value of name in the >> CONSTANT_NameAndType_info >> <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>. >> 4. These fields can also have a random order so we simply sort >> the entire byte code using `Arrays.sort(byte[])` to eliminate >> any differences due to ordering of fields/methods. >> 5. Simply sorting the byte array still had minute differences. I >> could not understand why they existed even though values in >> constant pool of the bytecode in allowlist and at runtime were >> exactly the same after rewriting. The differences existed in >> the bytes of the Code attribute of methods. I concluded that >> the bytes stored some position information. To avoid this, I >> created a subarray where I considered the bytes corresponding >> to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for >> it resulted in the same checksums for both classfiles. >> >> >> Let's understand the whole approach with an example of Proxy class. >> >> ` >> public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin { >> ` >> >> The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>". >> >> When the same class is intercepted at runtime, say "$Proxy10", we >> look for "Proxy_Plugin" in the allowlist and since the checksum >> algorithm is same in both cases, we get a match and let the class >> load. >> >> This approach has seemed to work well for Proxy classes, Generated >> Constructor Accessor (which is removed as you said). I also looked >> at the species generated by method handles. I did not notice any >> modification in them. Their name generation seemed okay to me. If >> some new Species are generated, it is of course detected since it >> is not in the allowlist. >> >> I have not looked into LambdaMetafactory because I did not >> encounter it as a problem so far, but I am aware its name >> generation is also unstable. I have run my approach only a few >> projects only. And for hidden classes, I assume the the agent >> won't be able to intercept them so detecting them would be really >> hard. >> >> >> Regards, >> Aman Sharma >> >> PhD Student >> KTH Royal Institute of Technology >> School of Electrical Engineering and Computer Science (EECS) >> Department of Theoretical Computer Science (TCS) >> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/> >> ------------------------------------------------------------------------ >> *From:* liangchenblue(a)gmail.com <mailto:liangchenblue@gmail.com> >> <liangchenblue(a)gmail.com> <mailto:liangchenblue@gmail.com> >> *Sent:* Thursday, May 16, 2024 5:52:03 AM >> *To:* Aman Sharma; core-libs-dev >> *Cc:* Martin Monperrus >> *Subject:* Re: Deterministic naming of subclasses of >> `java/lang/reflect/Proxy` >> Hi Aman, >> I think you meant CVE-2021-42392 instead of 2022. >> >> For your approach of an "allowlist" for Java runtime, project >> Leyden is looking to generate a static image [1], that >> > At run time it cannot load classes from outside the image, nor >> can it create classes dynamically. >> Leyden mainly avoids this unstable generation by performing a >> training run to collect classes loaded and even object graphs; I >> am not familiar with the details unfortunately. >> >> Otherwise, the Proxy discussion belongs better to core-libs-dev, >> as java.lang.reflect.Proxy is part of Java's core libraries. I am >> replying this thread to core-libs-dev. >> >> For your perceived problem that classes don't have unique names, >> your description sounds dubious: GeneratedConstructorAccessor is >> already retired by JEP 416 [2] in Java 18, and there are many >> other cases in which JDK generates classes without stable names, >> notoriously LambdaMetafactory (Gradle wished for cacheable >> Lambdas); the same applies for the generated classes for >> MethodHandle's LambdaForms (which carries implementation code for >> LambdaForm). How are you checking the classes? It seems you are >> not checking hidden classes. Proxy and Lambda classes are defined >> by the caller's class loader, while LambdaForms are under JDK's >> system class loader I think. We need to ensure you are correctly >> finding all unstable classes before we can proceed. >> >> [1]: https://openjdk.org/projects/leyden/notes/01-beginnings >> <https://openjdk.org/projects/leyden/notes/01-beginnings> >> [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416> >> >> On Wed, May 15, 2024 at 7:00 PM Aman Sharma <amansha(a)kth.se >> <mailto:amansha@kth.se>> wrote: >> >> Hi, >> >> >> My name is Aman and I am a PhD student at KTH Royal Institute >> of Technology, Stockholm, Sweden. I research as part of CHAINS >> <https://chains.proj.kth.se/> project to strengthen the >> software supply chain of multiple ecosystem. I particularly >> focus on runtime integrity in Java. In this email, I want to >> write about an issue I have discovered with /dynamic >> generation of `java.lang.reflect.Proxy`classes/. I will >> propose a solution and would love to hear the feedback from >> the community. Let me know if this is the correct mailing-list >> for such discussions. It seemed the most relevant from this >> list <https://mail.openjdk.org/mailman/listinfo>. >> >> >> *My research* >> >> * >> * >> >> Java has features to load class on the fly - it can either >> download or generate a class at runtime. These features are >> useful for inner workings of JDK. For example, implementing >> annotations, reflective access, etc. However, these features >> have also contributed to critical vulnerabilities in the past >> - CVE-2021-44228 (log4shell), CVE-2022-33980, CVE-2022-42392. >> All of these vulnerabilities have one thing in common - /a >> class that was not known during build time was >> downloaded/generated at runtime and loaded into JVM./ >> >> >> To defend against such vulnerabilities, we propose a solution >> to /allowlist classes for runtime/. This allowlist will >> contain an exhaustive list of classes that can be loaded by >> the JVM and it will be enforced at runtime. We build this >> allowlist from three sources: >> >> 1. All classes of all modules provided by the Java Standard >> Library. We use ClassGraph >> <https://github.com/classgraph/classgraph> to scan the JDK. >> 2. We can take the source code and all dependencies of an >> application. We use a software bill of materials to get >> all the data. >> 3. Finally, we use run the test suite to include any runtime >> downloaded/generated classes. >> >> Such a list is able to prevent the above 3 CVEs because it >> does not let the "unknown" bytecode to be loaded. >> >> *Problem with generating such an allowlist* >> * >> * >> The first two parts of the allowlist are easy to get. The >> problem is with the third step where we want to allowlist all >> the classes that could be downloaded or generated. Upon >> running the test suite and hooking to the classes it loads, we >> observer that the list consists of classes that are called >> "com/sun/proxy/$Proxy2", >> "jdk/internal/reflect/GeneratedConstructorAccessor3" among >> many more. The purpose of these classes can be identifed. The >> proxy class is created for to implement an annotation. The >> accessor gives access to constructor of a class to the JVM. >> >> When enforcing this allowlist at runtime, we see that the >> bytecode content for "com/sun/proxy/$Proxy2" differs in the >> allowlist and at runtime. In our case, we we are experimenting >> with pdfbox <https://github.com/apache/pdfbox> so we created >> the allowlist using its test suite. Then we enforced this >> allowlist while running some of its subcommands. However, >> there was some other proxy class say "com/sun/proxy/$Proxy5" >> at runtime that implemented the same interfaces and had the >> same methods as "com/sun/proxy/$Proxy2" in the allowlist. They >> only differed in the name of the class, order of fields, and >> types for fields references. This could happen because the >> order of the loading of class is workload dependent, but it >> causes problem to generate such an allowlist. >> >> *Solution >> * >> >> >> We propose that naming of subclasses of >> "java/lang/reflect/Proxy" should not be dependent upon the >> order of loading. In order to do so, two issues can be fixed: >> >> 1. The naming of the class should not be based on AtomicLong >> <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219…>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place. >> 2. Methods of the interfaces must be in a particular order. >> Right now, they are not sorted in any particular order >> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java…>. >> >> >> These fixes will make proxy class generation deterministic >> with respect to order of loading and won't be flagged at >> runtime since the test suite would already detect them. >> >> I would love to hear from the community about these ideas. If >> in agreement, I would be happy to produce a patch. I have >> discovered this issue with subclasses of >> GeneratedConstructorAccessor >> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/…> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research. >> >> I also have PoCs for the above CVEs >> <https://github.com/chains-project/exploits-for-sbom.exe> and >> a proof concept tool is being developed under the name >> sbom.exe <https://github.com/chains-project/sbom.exe> in case >> any one wonders about the implementation. I would also be >> happy to explain more. >> >> Regards, >> Aman Sharma >> >> PhD Student >> KTH Royal Institute of Technology >> School of Electrical Engineering and Computer Science (EECS) >> Department of Theoretical Computer Science (TCS) >> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/> >> > >

3 8

git: openjdk/leyden: premain: Fixed typo and added disclaimers
by duke 23 May '24

23 May '24

Changeset: 32811147 Author: iklam <ilam3388(a)gmail.com> Date: 2024-05-23 13:56:57 +0000 URL: https://git.openjdk.org/leyden/commit/3281114791cdd8198fe224b846d0d68b42aa8… Fixed typo and added disclaimers ! README.md

1 0

git: openjdk/leyden: premain: Moved Leyden overview docs to $REPO/README.md
by duke 23 May '24

23 May '24

Changeset: 8dee825a Author: iklam <ilam3388(a)gmail.com> Date: 2024-05-22 20:52:11 +0000 URL: https://git.openjdk.org/leyden/commit/8dee825af45ee8fd0766117127b7f9ee5b61d… Moved Leyden overview docs to $REPO/README.md ! README.md ! test/hotspot/jtreg/premain/README.md

1 0

git: openjdk/leyden: premain: Add snapshotting mechanism for training data
by duke 22 May '24

22 May '24

Changeset: 15f51139 Author: Igor Veresov <igor.veresov(a)oracle.com> Date: 2024-05-22 11:48:06 +0000 URL: https://git.openjdk.org/leyden/commit/15f51139f2d534f3f7a9143e746acdd6efdb9… Add snapshotting mechanism for training data ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp

1 0