RFR: 8330174: Establish no-access zone at the start of Klass encoding range [v2]

[Thomas Stuefe]

> After having reserved an address range for the Klass encoding range, we either:
> a) Place CDS, then class space, into that address range
> b) Place only class space in that range (if CDS is off).
> 
> For an nKlass of 0, the decoded Klasspointer points to the beginning of the encoding range. Since nKlass=0 is a special value, both CDS (a) and Metaspace (b) ensure that no Klass is placed right at the start of the Klass range.
> 
> However, it would also be good to establish a no-access zone at the range's start. Dereferencing an nKlass=0 would then result in an immediate, obvious crash instead of in reading invalid data.
> 
> This would closely mimic what we do in the compressed-oops-enabled java heap (albeit there we do it for fault-based null checks, too) and what Operating Systems do with low-address ranges.
> 
> ---
> 
> The patch:
> 
> We can neither move the encoding base down one page (the encoding base is carefully chosen to fit the platform's decoding). Nor can we move CDS archive space up one page (since CDS relies on the archive being placed exactly at the encoding base address). Nor do we want to move class space up (since class space start has a high alignment requirement of 16MB, protection zone would need to be 16MB large, which is a waste of address space).
> 
> Instead, as before, we just let Metaspace and CDS handle the protection zone internally. For Metaspace, this is very simple. We just protect the first page of class space. 
> 
> For CDS, it is a tiny bit more complex since we need to leave a "protection-zone-shaped hole" in the first region of the archive when we dump it. We do just that and then give that region a new property, "has protection zone". At runtime, we protect the underlying memory if a mapped region has a protection zone.
> 
> With CDS, because the page size can differ between dump- and runtime, the protection zone is the size of CDS core region alignment, not page-sized (e.g. dumping on Linux aarch64 with 4KB pages shall generate an archive that can be used in Docker on MacOS with 16KB pages).
> 
> ----
> 
> Tests:
> - ran CDS and AppCDS jtreg tests manually on Mac m1
> - manually tested that decoding, then dereferencing an nKlass=0 gives us the new "Fault address is narrow Klass base - dereferencing a zero nKlass?" output in the hs-err file
> - GHAs (which include the new regression test)

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into cds-metaspace-prot-prefix
 - Merge branch 'openjdk:master' into cds-metaspace-prot-prefix
 - Update metaspace.cpp
 - cds-metaspace-prot-prefix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19290/files
  - new: https://git.openjdk.org/jdk/pull/19290/files/983bf39d..0477e957

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19290&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19290&range=00-01

  Stats: 27773 lines in 580 files changed: 20211 ins; 5102 del; 2460 mod
  Patch: https://git.openjdk.org/jdk/pull/19290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19290/head:pull/19290

PR: https://git.openjdk.org/jdk/pull/19290