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.

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

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

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 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.

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

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.

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

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

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

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.

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.

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

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...).

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

And that's clearer / less invasive how?

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).

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.

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.