Teach vm.pmap.kernel_maps about both XN bits

[andrew]

Summary

The arm64 vm.pmap.kernel_maps sysctl would only check the kernel XN bit
when printing the kernel mapping. It can also be useful to check none
of the mappings allow userspace to execute from a given virtual address.
To check for this add the user XN bit when getting the kernel maps.

While here fix the ATTR_S1_AP_USER check to use ATTR_S1_AP to shift the
value to the correct offset.

[markj]

Is UXN ever legitimately unset for anything in the kernel maps?

[andrew]

It should always be set on kernel maps. I would expect any executable shared memory to be in the user address space.

Userspace can execute kernel code if it's missing, even if it can't read the memory, and we did have a bug in the past where the UXN bit was missing.

[markj]

sys/arm64/arm64/pmap.c

7007

I would represent !PXN as 'x' rather than 'X', to match the case of the other permission letters. !UXN is abnormal so its representation ought to look strange as well.

7052–7053

Hum, I think this code isn't right for table descriptors, which have their own encoding for access permissions. So the output of the sysctl might incorrectly report a mapping as executable when execution is in fact disabled by an earlier table entry.

... though apparently it's possible to disable enforcement of table attributes (HPDS), huh.

[andrew]

Swap x & X