Introduce AAL StrictProvenance flag, factor CDLList

[nwf]

CHERI will assert StrictProvenance (probably via AAL Mixin) and we can gate on that everywhere we need.

One such example is the contents of the CDDList nodes, where on non-StrictProvenance architectures, a relative encoding of the next pointer allows for tolerance of zero-initialized (and not constructed) values. For StrictProvenance, point explicitly at the next element but accept nullptr in lieu of this as the empty case.

With these (atop the other PRs I have open), we're back to being able to at least minimally run snmalloc on CHERI, but without capability bounds being enforced (that is, all pointers returned always authorize access to the entire underlying large allocation). Still, it's nice to be doing this in a way of which upstream approves, this time. :)

[mjp41]

My intent with this code for CHERI was that the CDLLNode would have the fields.

  CdLLNode* next, prev
  Ptrdiff_t to_next

to_next would be used for is_empty, and next to actually follow the pointer. This reduces the branching with an increase in meta data size. That is what I had meant by the comments in the code.

Do you think that doesn't work? Or did my comments not imply that to you? The comments are probably only sufficient for me to remember what I was thinking.

[davidchisnall]

Perhaps I'm missing something, but it looks as if this is used only for finding things inside a metaslab and is called only by the metaslab. Would it be possible instead to restructure this code so that we always passed a capability to the metaslab into the address calculations and did the offsetting relative to that?

[mjp41]

@davidchisnall, this a doubly linked list of slabs, but they can be in different superslabs, i.e. anywhere in memory. You would need to pass an all superslabs' metadata permissions. Which doesn't exist.

[davidchisnall]

That makes sense, thanks.

[nwf]

@mjp41 Ah! I took that to be "will need a real next pointer [in addition to the prev pointer]" not "[in addition to the to_next field]".

But: since the nullptr-related conditionals are straightforward (should be possible as conditional moves, not branches) and all this is already on a somewhat slow path of needing to grab another Slab, I'm not sure it's worth raising the CHERI minimum allocation size to (216 + 8 =) 40 bytes instead of just 2sizeof(void*) = 32?

[nwf]

I think this passes clangformat (at least, it does locally, but admittedly mine appears to behave slightly differently than the CI's), but something went terribly wrong in CI: fatal: bad object ca2a68d921e0485863d9bf5b1ad3e46eb7b82be9.

[mjp41]

Okay. Fair point re: min allocation size. Happy with your choice. We can always revisit. This is the second fastest path for allocation. So does occur reasonably often.

Re-running the CI to see what happened.

[mjp41]

I think CI is unhappy as you are not against the latest commit. I think the merge commit is not the value it thinks it should be so the line

git diff --exit-code $(Build.SourceVersion)

The $(Build.SourceVersion) is being filled in with an incorrect value. Would you be able to add another commit, that changes that line to

git diff --exit-code 

I think this should fix the error. I would sooner it be in a separate PR, but testing is easy with your current situation.

[mjp41]

LGTM