RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2]

[Andrew Dinn]

On Mon, 20 Mar 2023 15:07:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Regarding the motivation of this CR: I filled this RFE because I found the code confusing. When null_check() is called with an offset argument being klass_offset_in_bytes() and length_offset_in_bytes(), it never emits an explicit null check. And using this method, or methods calling it might give a false sense of security.

I doubt very much that there is a problem here. However, if there is one I believe it is to do with an unwary programmer not understanding how the implementation of calls with `_check_null` suffix work not whether they do what it says on the tin. The example cited here serves as a good vehicle to explain how that meainging is supported and show why it should give a perfectly solid sense of security.

This is all about what happens when the emitted code accesses address 0 i.e. the internal representation of null. When loading a `klass` from an oop that is null we can rely on a SIGSEGV handler to catch the error, because the first page of memory is RW protected. The `klass` offset is a small positive number well below the page size. That means we don't need a null check -- an access via null is guaranteed to land in that first page and we can defer handling of that access to the SIGSEGV handler.

As Roman indicated, the next step when we do enter the signal handler involves a lookup to see whether the PC at which the SEGV occurred is a legitimate one for a null dereference to occur. The compiler emits a list of such addresses for any given compiled method. If it is legitimate the handler ensures a NPE is delivered. If not it initiates a VM exit.

Clearly, we must plant an explicit null check for any access where we might offset beyond the first page of memory (offset >= page size). We may also end up accessing access a page that is not RW protected if the offset is negative -- well, arguably, any such page will also be in the unmapped address range for all supported OSes but we still allow for the possibility.

So, the `_null_check` variants do exactly what they say. They plant null checks where the SIGSEGV handler will not catch the error and only in those cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1477669181