updated code review request: 7099399: cannot deal with CRL file larger than 16MB (original) (raw)

Xuelei Fan xuelei.fan at oracle.com
Thu Oct 13 01:52:57 UTC 2011

Looks fine to me.

Xuelei

On 10/13/2011 3:12 AM, Weijun Wang wrote:

Sorry, a new updated webrev

http://cr.openjdk.java.net/~weijun/7099399/webrev.02/ Still, no change for the src file. The test now does not check the VM version anymore. Instead, it sets max heap size to 1024MB. I've tried some experiments on various systems. 250MB is OK for all client VMs, but even 512MB is not enough on a windows server VM. Therefore I choose 1024MB, it also makes the test runs faster. Also, David Holmes warned that a VM might report "Tiered" rather than "Server". The test passes on all JPRT platforms. Linux is fast (~1m), solaris-sparc slower (4m), and windows slowest (5m). I'll look at the memory usage (that is, 6670894) next week. Thanks Max On 10/12/2011 7:19 AM, Sean Mullan wrote: On 10/11/11 7:32 PM, Weijun Wang wrote:

Hi All

I've updated the webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.01/ I would like at least 2 reviewers. It might need to go to 7u2. The src file is identical to the last version, and I made several changes to the test: 1. Now run in othervm. Though hasn't made any changes to the VM, the huge memory footprint might prevent other tests to be running smoothly, at least before a full gc. 2. It only runs on "Server" VMs now. My last JPRT test shows it failing on all c1 VMs and succeeding on all c2 VMs. Is that the only way to determine if a server VM is being used? The name and whether it includes "Server" seems to be implementation specific. Otherwise looks fine to me. --Sean

I just finished a new JPRT test, all builds and tests pass on supported platforms. Thanks Max

On 10/10/2011 10:59 PM, Weijun Wang wrote: I'm now running JPRT tests on this fix. Unfortunately, for the 6 finished tests, I've already seen linux-i586 and solaris-i586 (both with c1 VM) failed on the new test with java.lang.OutOfMemoryError: Java heap space I guess our DER parsing codes are using too many memory. Maybe multiple copies of huge byte array here and there. In the short term, I'll see if I can rewrite the test with othervm and a proper -Xmx option. Hopefully customer dealing with these huge CRLs always use c2 VM with lots of memory. -Max On 10/10/2011 8:19 PM, Xuelei Fan wrote: Right! Then fine to me.

Thanks, Xuelei On 10/11/2011 11:13 AM, Weijun Wang wrote: 0xff will be 255, -1 means no byte to read, EOF.

On Oct 10, 2011, at 7:15 PM, Xuelei Fan<xuelei.fan at oracle.com> wrote: I'm not sure why the latest byte cannot be 0xFF? What about if my content length is 256? For example: 677 if (lowByte == -1) { 678 throw new IOException("Incomplete BER/DER length info"); 679 } Otherwise, looks fine to me. Xuelei On 10/11/2011 9:05 AM, Weijun Wang wrote: Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/ Basically, we're now accepting X.509 block of 4-octets length. For simplicity, the highest byte must be<= 127, so that the length can be expressed with a 32-bit int. Thanks Max

-------- Original Message -------- Change Request ID: 7099399 Synopsis: cannot deal with CRL file larger than 16MB Product: java Category: java Subcategory: classessecurity Type: Defect === Description ============================================================ The X.509 impl of CertificateFactory only parses X.509 blocks smaller than 16MB, i.e. when the length can be encoded in 3 octets. Now we have a customer whose CRL file is as big as 30MB.

More information about the security-dev mailing list