arm64: Add PROT_MTE to mmap

[andrew]

Summary

TODO: Needs checks to limit where it can be used, e.g. only
anonymous memory, & can't be shared between processes.

Sponsored by: Arm Ltd

[andrew]

This is not complete, but would be useful to get feedback on the approach

[andrew]

Only allow PROT_MTE with MAP_ANON

[andrew]

sys/vm/vm_mmap.c

283–287

Is this enough to stop creating shared mappings? I would like to not allow this until we understand how it will work with vMTE where tags are in the processes virtual address space.

[jrtc27]

sys/vm/vm_mmap.c

283–287

Are you sure you want to invest time going down the vMTE road?..

[andrew]

sys/vm/vm_mmap.c

283–287

No yet, but don't want to create an ABI we can't easily support with vMTE.

[brooks]

sys/arm64/arm64/pmap.c

5522

Even though it turns into a memattr, I think you're going to want a VM_PROT_MTE that is equal to PROT_MTE.

sys/sys/mman.h

60–64

I think _PROT_ARCH isn't going to be all that generic when you combing it with CHERI. I think it's better to have per-feature defines that get ORed into _PROT_ALL or used to compose _PROT_ARCH.

sys/vm/vm_mmap.c

283–287

For vMTE I think you'd need to prevent minherit(INHERIT_SHARE) as well.

[markj]

sys/arm64/arm64/pmap.c

5522

This block should assert that (m->oflags & VPO_UNMANAGED) == 0, otherwise it's unclear how the updates to the page's pv_flags are being synchronized. Even then, I'm not sure the object busy in vm_fault_soft_fast() is sufficient.

5525

What if we are entering a 2MB or 64KB page, i.e., psind > 0?

5525

What happens if an MTE page is mapped by other means, e.g., via pmap_enter_quick(), and tags aren't synced?

[andrew]

• Stop cleaning tags in pmap_enter after D57990
• Set the VM_MEMATTR_TAGGED attribute in more pmap functions
• Make PROT_MTE visible on all architectures
• Add VM_PROT_MTE
• Disallow chaning PROT_MTE in mprotect
• Also check if max_prot has PROT_MTE for non-anon mapping in mmap

mprotect doesn't allow changing PROT_MTE as it could either allow a bypass
of MTE, or for MTE to be used where it is unsupported.

[jrtc27]

Linux lets you mprotect(PROT_MTE) to enable it. I don't know about disabling.

[brooks]

sys/arm64/arm64/pmap.c

5522

Even though it turns into a memattr, I think you're going to want a VM_PROT_MTE that is equal to PROT_MTE.

I see you've added it. Anywhere below kern_mmap I'd suggest using VM_PROT_MTE over PROT_MTE

sys/sys/mman.h

58

In CheriBSD we've migrated to only defining the CHERI protections (PROT_CAP and PROT_NO_CAP) on architectures where they can be used.

I think I'd rather we not let PROT_MTE or VM_PROT_MTE leak below kern_mmap for architectures that can't support it.

[kib]

sys/sys/mman.h

59

What if we add machine/mman.h and move PROT_MTE to arm64/include/mman.h.
Same for CHERIX for relevant arches.

sys/mman.h would define e.g. PROT_MACHDEP1 and PROT_MACHDEP2.

sys/vm/vm.h

85

Similarly we can add machine/vmbits.h and move VM_PROT_MTE into arm64,

[jrtc27]

sys/sys/mman.h

59

I'd quite like PROT_CHERI[01] to have the same encoding across all CHERI architectures, rather than go down the Linux route of having everything gratuitously different across architectures, which to me means they should have central definitions (but can hide definitions when it's an error to use them). Especially since, with CHERI, the ifdef is MI, so you don't need to change any code to expose the definitions for a new CHERI architecture, it will happen automatically, whereas putting them in sys/foo/include/mman.h would require copying the exact same code around every time (sure, in this case "only" 2 lines, but why go with that when you can have 0 lines...).

[kib]

sys/sys/mman.h

59

Add mman_cheri.h and include it into machine/mman.h on arches that need it.

[jrtc27]

sys/sys/mman.h

59

And that's clearer / less invasive how?

[kib]

sys/sys/mman.h

59

It does not pollute the namespace with definitions that are irrelevant for arches which are not cheri. It leaves the bits unused and makes it available for other uses on other arches. It does not allow to irrelevant bits to pass checks (like PROT_ALL allowing PROT_MTE on arches != arm64).

[jrtc27]

sys/sys/mman.h

59

I encourage you to reread what I said and think about why I am arguing against some of those. I will also point out that PROT_ALL does *not* allow CHERI bits on non-CHERI architectures even in CheriBSD, and PROT_MTE being included here is something we are objecting to as well.

[kib]

sys/sys/mman.h

59

I re-read what you wrote. It does not change my position: arch-specific defines must go into the MD parts of the source tree. I believe I quite understand why do you object against what my position, but I do not want to put words in your mouth.

I object very hard against making the FreeBSD sources into some analog of subr_smp.c mess. In fact subr_smp.c is even not that bad comparing what is proposed right now.