By: dmcq (dmcq.delete@this.fano.co.uk), September 28, 2021 10:59 am
Room: Moderated Discussions
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.
> 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.
Topic | Posted By | Date |
---|---|---|
POWER10 SAP SD benchmark | anon2 | 2021/09/06 03:36 PM |
POWER10 SAP SD benchmark | Daniel B | 2021/09/07 02:31 AM |
"Cores" (and SPEC) | Rayla | 2021/09/07 07:51 AM |
"Cores" (and SPEC) | anon | 2021/09/07 03:56 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 03:24 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 03:27 PM |
Virtually tagged L1-caches | sr | 2021/09/08 05:49 AM |
Virtually tagged L1-caches | dmcq | 2021/09/08 08:22 AM |
Virtually tagged L1-caches | sr | 2021/09/08 08:56 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 08:58 AM |
Virtually tagged L1-caches | sr | 2021/09/08 10:09 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 10:46 AM |
Virtually tagged L1-caches | sr | 2021/09/08 11:35 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 12:23 PM |
Virtually tagged L1-caches | sr | 2021/09/08 12:40 PM |
Virtually tagged L1-caches | anon | 2021/09/09 03:16 AM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/10 05:19 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/10 06:59 AM |
Virtually tagged L1-caches | anon | 2021/09/14 03:17 AM |
Virtually tagged L1-caches | dmcq | 2021/09/14 09:34 AM |
Or use a PLB (NT) | Paul A. Clayton | 2021/09/14 09:45 AM |
Or use a PLB | Linus Torvalds | 2021/09/14 03:27 PM |
Or use a PLB | anon | 2021/09/15 12:15 AM |
Or use a PLB | Michael S | 2021/09/15 03:21 AM |
Or use a PLB | dmcq | 2021/09/15 03:42 PM |
Or use a PLB | Konrad Schwarz | 2021/09/16 04:24 AM |
Or use a PLB | Michael S | 2021/09/16 10:13 AM |
Or use a PLB | --- | 2021/09/16 01:02 PM |
PLB reference | Paul A. Clayton | 2021/09/18 02:35 PM |
PLB reference | Michael S | 2021/09/18 04:14 PM |
Demand paging/translation orthogonal | Paul A. Clayton | 2021/09/19 07:33 AM |
Demand paging/translation orthogonal | Michael S | 2021/09/19 09:10 AM |
PLB reference | Carson | 2021/09/20 10:19 PM |
PLB reference | sr | 2021/09/20 06:02 AM |
PLB reference | Michael S | 2021/09/20 07:03 AM |
PLB reference | Linus Torvalds | 2021/09/20 12:10 PM |
Or use a PLB | sr | 2021/09/20 04:32 AM |
Or use a PLB | sr | 2021/09/21 09:36 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 10:04 AM |
Or use a PLB | sr | 2021/09/21 10:48 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 01:55 PM |
Or use a PLB | sr | 2021/09/22 06:55 AM |
Or use a PLB | rwessel | 2021/09/22 07:09 AM |
Or use a PLB | Linus Torvalds | 2021/09/22 11:50 AM |
Or use a PLB | sr | 2021/09/22 01:00 PM |
Or use a PLB | dmcq | 2021/09/22 04:07 PM |
Or use a PLB | Etienne Lorrain | 2021/09/23 08:50 AM |
Or use a PLB | anon2 | 2021/09/22 04:09 PM |
Or use a PLB | dmcq | 2021/09/23 02:35 AM |
Or use a PLB | ⚛ | 2021/09/23 09:37 AM |
Or use a PLB | Linus Torvalds | 2021/09/23 12:01 PM |
Or use a PLB | gpd | 2021/09/24 03:59 AM |
Or use a PLB | Linus Torvalds | 2021/09/24 10:45 AM |
Or use a PLB | dmcq | 2021/09/24 12:43 PM |
Or use a PLB | sr | 2021/09/25 10:19 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 10:44 AM |
Or use a PLB | sr | 2021/09/25 11:11 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:31 AM |
Or use a PLB | sr | 2021/09/25 11:52 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 12:05 PM |
Or use a PLB | sr | 2021/09/25 12:23 PM |
Or use a PLB | rwessel | 2021/09/25 03:29 PM |
Or use a PLB | sr | 2021/10/01 12:22 AM |
Or use a PLB | rwessel | 2021/10/01 06:19 AM |
Or use a PLB | David Hess | 2021/10/01 10:35 AM |
Or use a PLB | rwessel | 2021/10/02 04:47 AM |
Or use a PLB | sr | 2021/10/02 11:16 AM |
Or use a PLB | rwessel | 2021/10/02 11:53 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:57 AM |
Or use a PLB | sr | 2021/09/25 12:07 PM |
Or use a PLB | Linus Torvalds | 2021/09/25 12:21 PM |
Or use a PLB | sr | 2021/09/25 12:40 PM |
Or use a PLB | nksingh | 2021/09/27 09:07 AM |
Or use a PLB | ⚛ | 2021/09/27 09:02 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 10:20 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 12:58 PM |
Or use a PLB | dmcq | 2021/09/28 10:59 AM |
Or use a PLB | sr | 2021/09/25 10:34 AM |
Or use a PLB | rwessel | 2021/09/25 03:44 PM |
Or use a PLB | sr | 2021/10/01 01:04 AM |
Or use a PLB | rwessel | 2021/10/01 06:33 AM |
I386 segmentation highlights | sr | 2021/10/04 07:53 AM |
I386 segmentation highlights | Adrian | 2021/10/04 09:53 AM |
I386 segmentation highlights | sr | 2021/10/04 10:19 AM |
I386 segmentation highlights | rwessel | 2021/10/04 04:57 PM |
I386 segmentation highlights | sr | 2021/10/05 11:16 AM |
I386 segmentation highlights | Michael S | 2021/10/05 12:27 PM |
I386 segmentation highlights | rwessel | 2021/10/05 04:20 PM |
Or use a PLB | JohnG | 2021/09/25 10:18 PM |
Or use a PLB | ⚛ | 2021/09/27 07:37 AM |
Or use a PLB | Heikki Kultala | 2021/09/28 03:53 AM |
Or use a PLB | rwessel | 2021/09/28 07:29 AM |
Or use a PLB | David Hess | 2021/09/23 06:00 PM |
Or use a PLB | Adrian | 2021/09/24 01:21 AM |
Or use a PLB | dmcq | 2021/09/25 12:41 PM |
Or use a PLB | blaine | 2021/09/26 11:19 PM |
Or use a PLB | David Hess | 2021/09/27 11:35 AM |
Or use a PLB | blaine | 2021/09/27 05:19 PM |
Or use a PLB | Adrian | 2021/09/27 10:40 PM |
Or use a PLB | Adrian | 2021/09/27 10:59 PM |
Or use a PLB | dmcq | 2021/09/28 07:45 AM |
Or use a PLB | rwessel | 2021/09/28 07:45 AM |
Or use a PLB | David Hess | 2021/09/28 12:50 PM |
Or use a PLB | Etienne Lorrain | 2021/09/30 01:25 AM |
Or use a PLB | David Hess | 2021/10/01 10:40 AM |
MMU privileges | sr | 2021/09/21 11:07 AM |
MMU privileges | Linus Torvalds | 2021/09/21 01:49 PM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/16 04:18 AM |
Virtually tagged L1-caches | Carson | 2021/09/16 01:12 PM |
Virtually tagged L1-caches | anon2 | 2021/09/16 05:16 PM |
Virtually tagged L1-caches | rwessel | 2021/09/16 06:29 PM |
Virtually tagged L1-caches | sr | 2021/09/20 04:20 AM |
Virtually tagged L1-caches | --- | 2021/09/08 02:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 08:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 08:34 PM |
Virtually tagged L1-caches | --- | 2021/09/09 10:14 AM |
Virtually tagged L1-caches | anonymou5 | 2021/09/09 10:44 PM |
Multi-threading? | David Kanter | 2021/09/09 09:32 PM |
Multi-threading? | --- | 2021/09/10 09:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 01:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 01:36 AM |
Virtually tagged L1-caches | --- | 2021/09/11 09:53 AM |
Virtually tagged L1-caches | sr | 2021/09/12 12:43 AM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/12 11:10 AM |
Virtually tagged L1-caches | sr | 2021/09/12 11:57 AM |
Virtually tagged L1-caches | dmcq | 2021/09/13 08:31 AM |
Virtually tagged L1-caches | sr | 2021/09/20 04:11 AM |
Virtually tagged L1-caches | sr | 2021/09/11 02:49 AM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/08 12:34 PM |
Virtually tagged L1-caches | dmcq | 2021/09/09 02:46 AM |
Virtually tagged L1-caches | dmcq | 2021/09/09 02:58 AM |
Virtually tagged L1-caches | sr | 2021/09/11 01:29 AM |
Virtually tagged L1-caches | dmcq | 2021/09/11 08:59 AM |
Virtually tagged L1-caches | sr | 2021/09/12 12:57 AM |
Virtually tagged L1-caches | dmcq | 2021/09/12 08:44 AM |
Virtually tagged L1-caches | sr | 2021/09/12 09:48 AM |
Virtually tagged L1-caches | dmcq | 2021/09/12 01:22 PM |
Virtually tagged L1-caches | sr | 2021/09/20 04:40 AM |
Where do you see this information? (NT) | anon2 | 2021/09/09 02:45 AM |
Where do you see this information? | sr | 2021/09/11 01:40 AM |
Where do you see this information? | anon2 | 2021/09/11 01:53 AM |
Where do you see this information? | sr | 2021/09/11 02:08 AM |
Thank you (NT) | anon2 | 2021/09/11 04:31 PM |