Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 27, 2021 12:58 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 27, 2021 10:20 am wrote:
> >
> > Oh, the implementation differences can be huge. Do you "integrate" the pointer
> > with the capability data like Cheri does? Or do you keep them independent so
> > that you can use one "segment" with multiple indexes (like i386 did)?
>
> Thinking about it, the biggest difference is not that the i386 model made the segment
> be very clearly separate from the pointer, but that the i386 segment model itself
> was based on indirection and explicit software management of segments.
>
> IOW, you never loaded "a segment". You loaded a "segment selector", and the hardware then
> looked up the actual segment data from a "segment table" (actually, two different ones,
> but at that point we're going off into "irrelevant implementation details" weeds).
>
> That makes perfect sense in one way, but one of the limitations in that segment model was that it didn't
> allow users of segments to easily "sub-segment" things or do other things on their own. The only thing you
> as a user saw was the selector value, and while you could query certain state (like the segment limit),
> you couldn't really do operations on segments - you had to create a new entry in the segment table.
>
> Contrast this to the Cheri model, which doesn't have that indirection through a segment table,
> and you can create a new segment ("capability pointer") from an existing valid one. So you
> can take a big segment, and create a new smaller subset of it (or a read-only one from a
> read-write one) and just use it without going through that "segment table" thing.
>
> Is that "fundamentally different"? No. The i386 model is one of an explicit software-managed segment
> table, while the Cheri one is comes with hardware support for managing your segments.
>
> Does the Cheri model seem much better? Ahh, there's the nub. It sure as heck looks a lot cleaner
> than i386 segments did (I say "i386", but it was really the 286 that introduced them).
>
> But looks can be deceiving.
>
> The Cheri model requires hidden bits of memory from hardware, for example.
> The Cheri model also makes all pointers really really big.
>
> So it's not some kind of "Cheri is obviously better". Cheri looks much nicer, but
> it has serious downsides, and the big difference is that we know the i386 model
> sucked, we don't have the same kind of lots of experience with the Cheri model.
>
> With Cheri you can do pointer compression (and if Cheri were to become popular, I bet people would
> try to do so), and you'd probably end up making your data structures use a lot of "index off a base
> pointer" instead of using a pointer. Because a 128-bit pointer is just really really big and wastes
> a lot of memory (it also has to be 128-bit aligned, because of how that verification bit works).
>
> That "pointer compression" was actually very very natural in the i386 model. It is not natural in the Cheri
> model. It requires that "one single base pointer". And that's fundamentally what the "segment selector" is.
>
> And yes, we've seen this before: people did some of that kind of work when moving to 64-bit
> architectures, and it sure wasn't all fun and games. On the whole, most projects kept using
> pointers, rather than "index plus base pointer", because managing the base pointer is just
> too painful, and it really doesn't work well when you have multiple allocations.
>
> And that "too painful" becomes even more true when you have
> segments / capability pointers and multiple allocations.
>
> Maybe the i386 segment model with pointer compression using
> explicit near and far pointers wasn't wrong after all?
>
> See? i386 segments really aren't so conceptually different from Cheri capability pointers. Very different
> implementation choices, and very different trade-offs. We know the i386 segment model was horrible
> to use. Does Cheri fix the problems? It's not immediately and trivially obvious. That "use index off
> a base pointer" doesn't look so different from near and far pointers, now does it?
>
> There's a reason Cheri is a "research project".
>
> But there is no real reason to claim that capabilities are fundamentally different from segments.
>
> Linus

THe bits of CHERI that worry me most are anything to do with revoking capabilities and stopping them being saved in a caled domain. THe i386 segments are easier that way but they just don't have the same flexibilty of use. I don't think conflating them achieves any useful purpose. There are other segment based system which are much closer like the Burroughs large systems for instance.