create a fork under openjdk

[Florian Weimer]

* Christine Flood:

> This leaves us with restored images having identical heap layouts.  This
> can be a great benefit.  I have seen cases where the kernel is smart enough
> to share the underlying pages.  However it can be a security risk.  If this
> is an important issue we can look at randomizing the java heap upon
> restore.  If we did a fullgc and tight compression of the heap before
> checkpointing we have all the information we need to do a fast random
> permutation on restore.  Please let me know if this is an important issue.

There's plenty of bytecode mapped at predictable addresses, and even one
RWX mapping:

/proc/3566599/maps:800000000-800003000 rwxp 00001000 103:02 91670724                        /usr/lib/jvm/java-15-openjdk-15.0.2.0.7-0.rolling.fc33.x86_64/lib/server/classes.jsa
/proc/3566599/maps:7f943475a000-7f9434a4a000 rwxp 00000000 00:00 0 
/proc/3566599/maps:7f9434e9b000-7f943537b000 rwxp 00000000 00:00 0 
/proc/3566599/maps:7f943c2fa000-7f943c56a000 rwxp 00000000 00:00 0 
/proc/3566619/maps:800000000-800003000 rwxp 00001000 103:02 91670724                        /usr/lib/jvm/java-15-openjdk-15.0.2.0.7-0.rolling.fc33.x86_64/lib/server/classes.jsa
/proc/3566619/maps:7f443075a000-7f44309ca000 rwxp 00000000 00:00 0 
/proc/3566619/maps:7f4430e9b000-7f443110b000 rwxp 00000000 00:00 0 
/proc/3566619/maps:7f44382fa000-7f443856a000 rwxp 00000000 00:00 0 

I understand the concern, but Hotspot is simply not hardened against
these kinds of issues.  The focus is more on prevent complete exploit
categories by ensuring both spatial and temporal memory safety in the
first place.  Not on post-exploitation countermeasures that rarely work
reliably in practice anyway.

Thanks,
Florian