RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions
I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. Performance gain of ~1.5x - 2x for message sizes 8k and above. - Commit messages: - Merge master - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions Changes: https://git.openjdk.java.net/jdk/pull/4019/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4019=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267125 Stats: 1017 lines in 21 files changed: 983 ins; 11 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019
Re: RFR: 8248268: Support KWP in addition to KW [v7]
> This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher > transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed > to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil > class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded > classes which extend FeedbackCipher and used in KeyWrapCipher class. To > minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto > operation over the same input buffer which is allocated and managed by > KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the > corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to > both KW and KWP. > > Thanks, > Valerie Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge master into JDK-8248268 - Minor update to address review comments. - Changed AESParameters to allow 4-byte, 8-byte IVs and removed KWParameters and KWPParameters. - Refactor code to reduce code duplication Address review comments Add more test vectors - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and AES/KWP/NoPadding - Restored Iv algorithm parameters impl. - 8248268: Support KWP in addition to KW Updated existing AESWrap support with AES/KW/NoPadding cipher transformation. Added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding support to SunJCE provider. - Changes: https://git.openjdk.java.net/jdk/pull/2404/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2404=06 Stats: 2592 lines in 16 files changed: 1930 ins; 555 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404
Re: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation [v3]
On Thu, 13 May 2021 23:53:18 GMT, Valerie Peng wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> in PKCS11 exception message when C_GetAttributeValue(...) call failed. The
>> java file changes are just cleanup for consolidating the CKR_* constants
>> definition into PKCS11Exception class.
>>
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional
> commit since the last revision:
>
> PKCS11Exception class refactoring - use enum instead of HashMap
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
line 212:
> 210: long value() {
> 211: return value;
> 212: }
I guess it is safe to use the 'value' variable directly for enum. The value()
method may be not necessary. Just a personal preference, ignore it if you like
the current way.
-
PR: https://git.openjdk.java.net/jdk/pull/3709
Re: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation [v3]
> Anyone can help review this somewhat trivial fix? The main change is inside > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to > help better troubleshooting by reporting the type of unavailable attributes > in PKCS11 exception message when C_GetAttributeValue(...) call failed. The > java file changes are just cleanup for consolidating the CKR_* constants > definition into PKCS11Exception class. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: PKCS11Exception class refactoring - use enum instead of HashMap - Changes: - all: https://git.openjdk.java.net/jdk/pull/3709/files - new: https://git.openjdk.java.net/jdk/pull/3709/files/285196b4..c08f62f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3709=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3709=01-02 Stats: 244 lines in 1 file changed: 117 ins; 102 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3709/head:pull/3709 PR: https://git.openjdk.java.net/jdk/pull/3709
Re: JEP411: Missing use-case: Monitoring / restricting libraries
I also think good developers will add these security features. The problem is that Permissions are currently used to regulate access control because this is how we've been told it should be done for over 20 years. Now maybe people aren't using the Java FilePolicy provider (for reasons stated previously), but as has been discovered, they often will override SecurityManager and implement some form of access control on trusted 3rd party code. Trusted code - Developed by people with good intentions - includes third party library code, we check it for known vulnerabilities at build time using OWASP, but we don't audit it ourselves as this requires understanding how the internals work and we are using it like a black box. If we have concerns we might perform static analysis, but we don't do that for dynamic code, eg maven dependencies and then we are powerless to do anything about it, other than report the bug, so access control can be used to mitigate until it's fixed, or we can use the principle of least privilege so we are not impacted by it. Java Serialization is also a form of parsing information, just like PDF documents and other file formats, problems with the Sandbox; there was no Permission to limit which classes could be deserialized, and JVM code always has AllPermission, so we couldn't restrict it either. Additionally there was no ProtectionDomain to represent the data being deserialized, and whether it was trusted or untrusted, these security features wouldn't have been difficult to add, however we rely on the platform developers to see the benefits. We are all only human. In JGDMS there are constraints we apply to services which require authentication and encryption, which must be met before deserialization or any downloads can proceed. In our re-implementation of Atomic Java Serialization, we use a DeserizablePermission, to limit which libraries can perform de-serialization. This is in addition to the use of failure atomic constructors, so we don't break object encapsulation. We also perform static analysis at build time and fix these bugs too. SecurityManager has much influence in access decisions in our software, we won't have the resources to upgrade, there's a massive amount of security auditing required before we could even consider it. Our only option is to participate in the maintenance of existing Java versions. Java will be our COBOL. We will be capable of using Java 1.8 to 1.17, but not Java 2.0 (after disablement occurs). Obviously removing SecurityManager infrastructure from OpenJDK is a significant undertaking requiring significant resources to audit the impacts of removal of Permission checks, unfortunately we don't have these resources and the alternative methods of putting alternative access controls in place isn't obvious and will require research, as you state below, I know very little about how this can be done without using existing Java access controls. I think during this transition period, while developers are reestablishing what constitutes secure programming, there will be many new bugs exposed that SecurityManager was obscuring. Personally, I will be observing from the sidelines to learn new security features and best practices I'm not yet aware of. It's always best to wait and see the outcome of experiments before diving in. The problem with Security is many developers don't like it, or want it to be someone else's problem, so we will always have reasons to remove whatever Security API's are added to Java because of limited use. Perhaps I'm conflating security with access control again? -- Regards, Peter On 14/05/2021 2:15 am, Sean Mullan wrote: On 5/12/21 5:41 PM, Peter Tribble wrote: Let me give a concrete example: Parsing and rendering a PDF file that may contain references to fonts or other resources. We know exactly where the files are installed, so wish to allow the rendering routine access to the fonts it will need. But not to any other files, and not (normally) to network resources at all. Note that we trust the code, but not necessarily the document it's parsing. (Although the document itself may be perfectly well formed - document formats often allow embedding references to 3rd-party objects, undesirable as that may be.) There are a range of such issues in document parsing and rendering. And unfortunately, the good libraries for this task are proprietary so we can't modify them to apply the restrictions we're after. The (server-side) application does need access to files and network resources at other times; it's only when it goes into the rendering step that we lock it down, and unlock it once done. I know very little about this area, but I would think a good PDF rendering library would include security features which prevent arbitrary file/network access from untrusted documents by default or at least give you the ability to control that. --Sean
Re: RFR: JDK-6676643: Improve current C_GetAttributeValue native implementation [v2]
On Wed, 12 May 2021 21:58:13 GMT, Valerie Peng wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> in PKCS11 exception message when C_GetAttributeValue(...) call failed. The
>> java file changes are just cleanup for consolidating the CKR_* constants
>> definition into PKCS11Exception class.
>>
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix typos, e.g. funktion, lsit, functin.
Looks good to me except a few trivial comments.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
line 193:
> 191: register("CKR_TOKEN_RESOURCE_EXCEEDED", 0x0201L);
> 192: register("CKR_OPERATION_CANCEL_FAILED", 0x0202L);
> 193: register("CKR_VENDOR_DEFINED", 0x8000L);
See below comment, I may have the hash map unmodifiable after the registration.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
line 197:
> 195:
> 196: private static void register(String name, long errorCode) {
> 197: errorMap.put(errorCode, name);
I may check the put() return value and throw error for duplicated items, just
in case duplicated copy-and-past register.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java
line 205:
> 203: if (res == null) {
> 204: res = "0x" + Functions.toFullHexString((int)errorCode);
> 205: errorMap.put(errorCode, res);
It would be nice if the errorMap is immutable once the known error codes get
registered.
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3709
Integrated: 8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java
On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the following test code reviewed? > > The test SSLEngineExplorerMatchedSNI.java fails intermittently. I tried to > run the test 500 times, but cannot reproduce the issue. The cause is unknown > to me now. It would could be helpful to fine the root cause to enable the > JSSE debugging in the test. > > Thanks & Regards, > Xuelei This pull request has now been integrated. Changeset: 26670245 Author:Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/266702451db57c4f006f22601288174cc0613339 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java Reviewed-by: hchao, mullan - PR: https://git.openjdk.java.net/jdk/pull/3967
Re: RFR: 8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java
On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the following test code reviewed? > > The test SSLEngineExplorerMatchedSNI.java fails intermittently. I tried to > run the test 500 times, but cannot reproduce the issue. The cause is unknown > to me now. It would could be helpful to fine the root cause to enable the > JSSE debugging in the test. > > Thanks & Regards, > Xuelei Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3967
Re: RFR: 8248268: Support KWP in addition to KW [v6]
> This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher > transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed > to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil > class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded > classes which extend FeedbackCipher and used in KeyWrapCipher class. To > minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto > operation over the same input buffer which is allocated and managed by > KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the > corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to > both KW and KWP. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor update to address review comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2404/files - new: https://git.openjdk.java.net/jdk/pull/2404/files/eec0dab6..e4421a8d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2404=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2404=04-05 Stats: 71 lines in 2 files changed: 48 ins; 1 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404
Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 5/12/21 5:41 PM, Peter Tribble wrote: Let me give a concrete example: Parsing and rendering a PDF file that may contain references to fonts or other resources. We know exactly where the files are installed, so wish to allow the rendering routine access to the fonts it will need. But not to any other files, and not (normally) to network resources at all. Note that we trust the code, but not necessarily the document it's parsing. (Although the document itself may be perfectly well formed - document formats often allow embedding references to 3rd-party objects, undesirable as that may be.) There are a range of such issues in document parsing and rendering. And unfortunately, the good libraries for this task are proprietary so we can't modify them to apply the restrictions we're after. The (server-side) application does need access to files and network resources at other times; it's only when it goes into the rendering step that we lock it down, and unlock it once done. I know very little about this area, but I would think a good PDF rendering library would include security features which prevent arbitrary file/network access from untrusted documents by default or at least give you the ability to control that. --Sean
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
Just to add another point to this. Today it is quite hard to use operating
system facilities like chroot/jails, security tokens, seteuid, dropping
priveledges or switching Security tokens which would allow to limit or escalate
priveledges in an OS enforced manor. If we would have a bit more support of
that, some sandbox mechanisms might actually be able to replace a security
manager and/or open new features like processing workload with actual user
accounts, etc.
I am however not sure what mechanism would be needed (and possible given the
complete runtime) for that and how to make it able to support multiple OS with
that. Maybe it would be an os specific optional facility? Something like SAPs
shared memory with multiple processes maybe as an option for easy spawning of
contained worklads?
--
http://bernd.eckenfels.net
Von: security-dev im Auftrag von Peter
Tribble
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler
Cc: Alan Bateman ; Peter Firmstone
; security-dev@openjdk.java.net
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring /
restricting libraries
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
mailto:ron.press...@oracle.com>> wrote:
> On 12 May 2021, at 22:41, Peter Tribble
> mailto:peter.trib...@gmail.com>> wrote:
>
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> We know exactly where the files are installed, so wish to allow the rendering
> routine access
> to the fonts it will need. But not to any other files, and not (normally) to
> network resources at
> all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> document itself may be perfectly well formed - document formats often allow
> embedding
> references to 3rd-party objects, undesirable as that may be.)
>
Thank you. Let me ask you this, then:
1. Would allowing access to certain files and no network for the *entire*
application be
sufficient? Consider that you can run some code in a separate Java process with
OS protections.
If not, why not?
Unfortunately not. We're already running this in a separate sandboxed Java
process to provide a
basic level of isolation. But that process has to interact with the outside
world - it has to get the
file in the first place, and put the result somewhere (which may be to a
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary
depending on where we are
in the rendering process.
2. Would turning such access on and off for the entire application through some
Java process
be sufficient?
That's effectively what we're doing right now. Essentially we do:
doRender() {
installSecurityManager();
do3rdPartyRender();
uninstallSecurityManager();
}
which is fine because we are in a dedicated sandbox and can be sure that we
aren't doing anything else
at the time.
3. Would controlling such access on a per-thread basis be sufficient?
In a way, that would be more flexible, as we wouldn't need the stop-the-world
blanket restriction.
It does, however, rely on the assumption that once you've applied the
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that thread.
In our specific use case, because we have separate processes already, we would
probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it
allows you to tie a restriction to
a given execution context.
Please don’t read 2 or 3 as some concrete proposals; I’m just trying to
understand the requirements.
— Ron
Thanks,
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 5/13/21 6:00 AM, Ron Pressler wrote: On 13 May 2021, at 10:32, Peter Firmstone wrote: So it targets 17. I don’t know. I think that’s still TBD, but perhaps others know more. At this point, yes, we are planning to target the JEP to JDK 17. It would be nice to have certainty about which release it will be removed from, for planning purposes. Again it would seem that this isn't a consideration of OpenJDK. It very much is, which is why we have the deprecation and removal policy. Please read the JEP carefully. In addition to deprecation and removal, this JEP also proposes an interim step of degradation prior to removal. Removal, as the JEP says, will only be done once it no longer poses a big compatibility threat. At the fastest pace possible removal is more than a year away, though it will likely be longer than that. The JEP does have a section on this: "In future JDK releases, we may degrade the Security Manager APIs so that they remain in place but have limited or no functionality. For example, we may revise AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager always to return null. This would allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. Once the compatibility risk has declined to an acceptable level, we expect to remove the APIs." So, if the JEP is targeted to 17, then the Security Manager will be deprecated for removal but will still be fully functional and supported in 17. *Disclaimer: The next part is forward thinking, and subject to change.* Once we start degrading the APIs, the functionality of the Security Manager may not fully work as before, so in that sense you might consider it "removed". We don't yet have a definitive timeline for that, it may occur in the next release, or it may not, but it will probably occur within a few releases after the release it is targeted to. --Sean Is there an OpenJDK community project group that maintains older Java versions I can join? Yes, that would be the Updates Project. — Ron
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v19]
> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Rename is_entry_blob to is_optimized_entry_blob Rename as_entry_blob to as_optimized_entry_blob Fix misc typos and indentation issues - Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/3f99cccf..352c287f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=17-18 Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v19]
On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Rename is_entry_blob to is_optimized_entry_blob > Rename as_entry_blob to as_optimized_entry_blob > Fix misc typos and indentation issues Marked as reviewed by vlivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3699
Integrated: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption
On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini wrote: > test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior > when a server closes the socket connection during a handshake. The server was > waiting a fixed 100ms before closing it, but there was no guarantee that the > client started the handshake before or during that time frame > > With this changeset, the server is checking whether the client thread has > initiated handshake, and retrying if needed after waiting a short time. In > addition, the test is now reusing SSLSocketTemplate to simplify sockets > configuration and client/server synchronization This pull request has now been integrated. Changeset: 347d41df Author:Fernando Guallini Committer: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/347d41df909f5762c5e066ab70d0fe7ea500ffaf Stats: 114 lines in 1 file changed: 50 ins; 50 del; 14 mod 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption Reviewed-by: dfuchs, rhalade - PR: https://git.openjdk.java.net/jdk/pull/3856
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v18]
> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Take care of remaining references to "Panama" - * Replace is_panama_entry_frame() with is_optimized_entry_frame() * Replace EntryBlob with OptimizedEntryBlob - Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/03662920..3f99cccf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=16-17 Stats: 45 lines in 15 files changed: 1 ins; 1 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
> On 13 May 2021, at 03:11, David Black wrote: > > > This seems somewhat more useful than 1 & 2 but imho it would be better to be > able to perform checks/grant access on a call stack basis. This is an important point we’re trying to get across. The very reason the Security Manager was made this way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of experience have shown us that *in practice* this is not the case, certainly not when you look at the ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets the job done, but actually use it incorrectly, providing the illusion of security without actual security. > Atlassian currently makes use of a security manager to prevent access to > cloud metadata services that do not have an amazon sdk related class on the > call stack. This helps to mitigate the impact of SSRF in applications running > in a cloud environment > (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager). We’re talking about a situation where *all* the classes running in your application are trusted, i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them. Can you explain why you believe this mechanism, that treats different classes differently is the best way to improve security? — Ron
Re: JEP411: Missing use-case: Monitoring / restricting libraries
> On 13 May 2021, at 10:32, Peter Firmstone wrote: > > So it targets 17. I don’t know. I think that’s still TBD, but perhaps others know more. > > It would be nice to have certainty about which release it will be removed > from, for planning purposes. Again it would seem that this isn't a > consideration of OpenJDK. It very much is, which is why we have the deprecation and removal policy. Please read the JEP carefully. In addition to deprecation and removal, this JEP also proposes an interim step of degradation prior to removal. Removal, as the JEP says, will only be done once it no longer poses a big compatibility threat. At the fastest pace possible removal is more than a year away, though it will likely be longer than that. > > Is there an OpenJDK community project group that maintains older Java > versions I can join? > Yes, that would be the Updates Project. — Ron
Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2]
On Mon, 10 May 2021 11:00:34 GMT, Julia Boes wrote: > @fguallini I'm happy to sponsor this change once it's been reviewed by > someone from security. Thank you for sponsoring!. Rajan has reviewed the PR, it should be ready for integration. - PR: https://git.openjdk.java.net/jdk/pull/3856
Re: JEP411: Missing use-case: Monitoring / restricting libraries
So it targets 17. Java 8 has planned support to 2030, longer than 17, it seems unlikely the SecurityManager will still be present in an LTS release later than 17, given that 11 was the last, maybe 23 will be the next LTS version. Of course these aren't OpenJDK considerations, maybe someone will decide to support a version of Java that has it longer, or maybe they wont. It would be nice to have certainty about which release it will be removed from, for planning purposes. Again it would seem that this isn't a consideration of OpenJDK. Is there an OpenJDK community project group that maintains older Java versions I can join? Regards, Peter. On 13/05/2021 6:21 pm, Ron Pressler wrote: Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even if 411 targets 17, the Security Manager will still be in 17, precisely because of the deprecation policy intended to give people time to adjust. — Ron On 13 May 2021, at 01:44, Peter Firmstone wrote: Ron, Can JEP 411 be targeted against Java 18 please? I realize long term support is not OpenJDK's concern, however other's are planning Java 17 to be a long term support release and that will impact us. Thank you, Peter Firmstone Zeus Project Services Pty Ltd. On 13/05/2021 7:43 am, Ron Pressler wrote: On 8 May 2021, at 05:55, Peter Firmstone wrote: What would help in future: • Define a core Java api, a javadoc annotation? If parts of it are deprecated, they will not be removed for eg 3 LTS releases, pick a number, it provides certainty. Developers writing new software then know if they use this api, they will not be harmed by breaking changes for x years. • Removal of api from java.* or javax.* are breaking changes. This is worse than a library breakage, as we can write a compatibility layer for a library. In my own software I provide a compatibility library for older versions of software written for Jini, it just decorates old api over new as a compatibility layer. For example we could write a compatibility layer for AccessController and doPrivileged methods, so they still work, without shotgun surgery. but we can't do that because it's in Java package namespace. • An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt. OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.” Long-term support is a general term for services that anyone is free to offer for any OpenJDK version for any length of time, and even retroactively. You can choose to provide LTS to JDK 10 tomorrow if you like. OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal is to do exactly what you describe, and that policy is in effect for this JEP as it is for all other similar ones. But please read JEP 411 carefully. It does give you time; it does talk of a gradual process. • Sun always gave us plenty of time to remove usages of deprecated methods, it always took years to clean these up, but there are compiler warnings etc. My point is, we always got them removed eventually, meanwhile we were also able to take advantage of new features. This is the second time you’ve brought up Sun, as if it’s some disjoint group of people. People might have decided to change their policies due to changing circumstances, and the circumstances 15 years ago were certainly no identical to today. It appears to me that stack walking, which you singled out as a performance problem (it isn't), is likely causing difficulties for another project you're working on, which is why you are strongly motivated to see it removed. We would like to see it removed because we believe that the total good the Security Manager does the Java community as a whole does not appear to justify its high cost. In other words, we’d like to see it removed because we believe doing so would do more good for more people than not removing it. This will inflict pain on many projects, I just can't see people upgrading their software. Who's going to pay for all the hours of programming to convert perfectly good running code to a new api, just to upgrade to a newer version of Java? Removing stuff absolutely causes pain. We know that, we sympathise, and we’re trying to minimise it. But you have to understand that *not* removing stuff also causes pain, and not diverting resources elsewhere might dissuade other people from using Java because *their* needs aren’t addressed. We would have loved to please everyone but it’s impossible, so we have to make decisions, and whatever decision we make, someone will experience pain in the form of more work they have to do. We have to consider the total pain vs. total good over the entire Java ecosystem. Please also understand our perspective: you’re asking us to pay for hours of work to maintain something that few use, hours that could go into work more people could
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v17]
> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address CSR comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/6701654c..03662920 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=15-16 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699
Re: JEP411: Missing use-case: Monitoring / restricting libraries
Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even if 411 targets 17, the Security Manager will still be in 17, precisely because of the deprecation policy intended to give people time to adjust. — Ron > On 13 May 2021, at 01:44, Peter Firmstone wrote: > > Ron, > > Can JEP 411 be targeted against Java 18 please? > > I realize long term support is not OpenJDK's concern, however other's are > planning Java 17 to be a long term support release and that will impact us. > > Thank you, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > On 13/05/2021 7:43 am, Ron Pressler wrote: >> >>> On 8 May 2021, at 05:55, Peter Firmstone >>> wrote: >>> >>> What would help in future: >>> >>> • Define a core Java api, a javadoc annotation? If parts of it are >>> deprecated, they will not be removed for eg 3 LTS releases, pick a number, >>> it provides certainty. Developers writing new software then know if they >>> use this api, they will not be harmed by breaking changes for x years. >>> • Removal of api from java.* or javax.* are breaking changes. This is >>> worse than a library breakage, as we can write a compatibility layer for a >>> library. In my own software I provide a compatibility library for older >>> versions of software written for Jini, it just decorates old api over new >>> as a compatibility layer. For example we could write a compatibility >>> layer for AccessController and doPrivileged methods, so they still work, >>> without shotgun surgery. but we can't do that because it's in Java package >>> namespace. >>> • An annotation will let us know that we can write programs, without >>> risk of incurring potentially significant technical debt. >> OpenJDK does not have the concept of LTS, and certainly not of "LTS >> releases.” >> Long-term support is a general term for services that anyone is free to >> offer for any OpenJDK version for >> any length of time, and even retroactively. You can choose to provide LTS to >> JDK 10 tomorrow if you like. >> >> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its >> goal is to do exactly what >> you describe, and that policy is in effect for this JEP as it is for all >> other similar ones. >> >> But please read JEP 411 carefully. It does give you time; it does talk of a >> gradual process. >> >> >> >>> • Sun always gave us plenty of time to remove usages of deprecated >>> methods, it always took years to clean these up, but there are compiler >>> warnings etc. My point is, we always got them removed eventually, >>> meanwhile we were also able to take advantage of new features. >> This is the second time you’ve brought up Sun, as if it’s some disjoint >> group of people. People might >> have decided to change their policies due to changing circumstances, and the >> circumstances 15 years >> ago were certainly no identical to today. >> >> >>> It appears to me that stack walking, which you singled out as a performance >>> problem (it isn't), is likely causing difficulties for another project >>> you're working on, which is why you are strongly motivated to see it >>> removed. >> We would like to see it removed because we believe that the total good the >> Security Manager does the >> Java community as a whole does not appear to justify its high cost. In other >> words, we’d like to see it >> removed because we believe doing so would do more good for more people than >> not removing it. >> >>> This will inflict pain on many projects, I just can't see people upgrading >>> their software. Who's going to pay for all the hours of programming to >>> convert perfectly good running code to a new api, just to upgrade to a >>> newer version of Java? >> Removing stuff absolutely causes pain. We know that, we sympathise, and >> we’re trying to minimise it. >> But you have to understand that *not* removing stuff also causes pain, and >> not diverting resources >> elsewhere might dissuade other people from using Java because *their* needs >> aren’t addressed. We would >> have loved to please everyone but it’s impossible, so we have to make >> decisions, and whatever decision >> we make, someone will experience pain in the form of more work they have to >> do. We have to consider the >> total pain vs. total good over the entire Java ecosystem. Please also >> understand our perspective: you’re >> asking us to pay for hours of work to maintain something that few use, hours >> that could go into work more >> people could enjoy. >> >> — Ron >
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
wrote:
>
> > On 12 May 2021, at 22:41, Peter Tribble wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed, so wish to allow the
> rendering routine access
> > to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> > all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> > document itself may be perfectly well formed - document formats often
> allow embedding
> > references to 3rd-party objects, undesirable as that may be.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>
Unfortunately not. We're already running this in a separate sandboxed Java
process to provide a
basic level of isolation. But that process has to interact with the outside
world - it has to get the
file in the first place, and put the result somewhere (which may be to a
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary
depending on where we are
in the rendering process.
> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>
That's effectively what we're doing right now. Essentially we do:
doRender() {
installSecurityManager();
do3rdPartyRender();
uninstallSecurityManager();
}
which is fine because we are in a dedicated sandbox and can be sure that we
aren't doing anything else
at the time.
> 3. Would controlling such access on a per-thread basis be sufficient?
>
In a way, that would be more flexible, as we wouldn't need the
stop-the-world blanket restriction.
It does, however, rely on the assumption that once you've applied the
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that
thread.
In our specific use case, because we have separate processes already, we
would probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it
allows you to tie a restriction to
a given execution context.
> Please don’t read 2 or 3 as some concrete proposals; I’m just trying to
> understand the requirements.
>
> — Ron
>
>
Thanks,
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v16]
On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore wrote: >> src/hotspot/share/runtime/sharedRuntime.hpp line 465: >> >>> 463: static void restore_native_result(MacroAssembler *_masm, BasicType >>> ret_type, int frame_slots); >>> 464: >>> 465: static void move32_64(MacroAssembler* masm, VMRegPair src, >>> VMRegPair dst); >> >> Please, file an RFE to move these declarations to `MacroAssembler`. > > There's already an issue for that: > https://bugs.openjdk.java.net/browse/JDK-8266257 > > I've upgraded the description to make it reflect the proposed move a bit more > precisely. Got it. I was confused by the bug synopsis. - PR: https://git.openjdk.java.net/jdk/pull/3699
